lkml.org 
[lkml]   [2014]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/5] rhashtable: Remove gfp_flags from insert and remove functions
On 09/15/14 at 05:35am, Eric Dumazet wrote:
> On Mon, 2014-09-15 at 14:18 +0200, Thomas Graf wrote:
> > 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.

> > - tbl = kzalloc(size, flags);
> > + tbl = kzalloc(size, GFP_KERNEL);
>
> Add __GFP_NOWARN, as you fallback to vzalloc ?

Good point.

> btw, inet hash table uses alloc_large_system_hash() which spreads the
> pages on all available NUMA nodes :
>
> # dmesg | grep "TCP established"
> [ 1.223046] TCP established hash table entries: 524288 (order: 10, 4194304 bytes)
> # grep alloc_large_system_hash /proc/vmallocinfo | grep pages=1024
> 0xffffc900181d6000-0xffffc900185d7000 4198400 alloc_large_system_hash+0x177/0x237 pages=1024 vmalloc vpages N0=512 N1=512
> 0xffffc900185d7000-0xffffc900189d8000 4198400 alloc_large_system_hash+0x177/0x237 pages=1024 vmalloc vpages N0=512 N1=512
> 0xffffc90028a01000-0xffffc90028e02000 4198400 alloc_large_system_hash+0x177/0x237 pages=1024 vmalloc vpages N0=512 N1=512
>
> So we might keep in mind to keep this numa policy.

Agreed. Will introduce this through a table parameter option when
converting the inet hash table.


\
 
 \ /
  Last update: 2014-09-15 15:21    [W:0.058 / U:1.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site