On Tue, Feb 07, 2017 at 07:02:16PM +0100, Florian Westphal wrote:
>
> I can't really say anything here because *I* don't expect
> it to succeed.
Think about incoming TCP connections, you can't rate-limit that
without defeating yourself.
> Even with this proposed patch things will eventually fail
Herbert Xu wrote:
> On Tue, Feb 07, 2017 at 02:17:28PM +0100, Florian Westphal wrote:
> >
> > Ok, but why?
>
> Because people expect the hash table insertion to succeed, even
> on softirq paths where you cannot vmalloc.
I can't really say anything here because *I* don't expect
it to succeed.
>
On Tue, Feb 07, 2017 at 02:17:28PM +0100, Florian Westphal wrote:
>
> Ok, but why?
Because people expect the hash table insertion to succeed, even
on softirq paths where you cannot vmalloc.
> It seems to add a whole lot of complexity...
>
> What users can't handle the insert failure case until r
Herbert Xu wrote:
> This patch adds code that handles GFP_ATOMIC kmalloc failure on
> insertion. As we cannot use vmalloc, we solve it by making our
> hash table nested. That is, we allocate single pages at each level
> and reach our desired table size by nesting them.
>
> When a nested table i
