lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 15 Sep 2014 13:49:37 +0100
From:	Thomas Graf <tgraf@...g.ch>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	davem@...emloft.net, paulmck@...ux.vnet.ibm.com,
	john.r.fastabend@...el.com, kaber@...sh.net,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists