Re: [PATCH 1/5] rhashtable: Remove gfp_flags from insert and remove functions

Thomas Graf [off-list ref] writes:

On 09/15/14 at 05:35am, Eric Dumazet wrote:

quoted

On Mon, 2014-09-15 at 14:18 +0200, Thomas Graf wrote:

quoted

As the expansion/shrinking is moved to a worker thread, no allocations
will be performed anymore.

You meant : no GFP_ATOMIC allocations ?

I would rephrase using something like :

Because hash resizes are potentially time consuming, they'll be
performed in process context where GFP_KERNEL allocations are preferred.

I meant to say no allocations in insert/remove anymore but your wording
is even clearer. I'll update it.

quoted

quoted

-	tbl = kzalloc(size, flags);
+	tbl = kzalloc(size, GFP_KERNEL);

Add __GFP_NOWARN, as you fallback to vzalloc ?

Good point.

It needs to be both __GFP_NOWARN and __GFP_NORETRY.

Otherwise the system will kick in the OOM killer before it falls back to
vzalloc.  Which I can't imagine anyone wanting.

Look at the history of alloc_fdmem in fs/file.c for the real world
reasoning.

Eric