netdev - Re: [v1 PATCH 9/10] rhashtable: Allow GFP

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:	Tue, 24 Mar 2015 14:09:13 +1100
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Laight <David.Laight@...LAB.COM>
Cc:	"David S. Miller" <davem@...emloft.net>,
	Thomas Graf <tgraf@...g.ch>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Patrick McHardy <kaber@...sh.net>,
	Josh Triplett <josh@...htriplett.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [v1 PATCH 9/10] rhashtable: Allow GFP_ATOMIC bucket table
 allocation

On Mon, Mar 23, 2015 at 12:53:11PM +0000, David Laight wrote:
>
> Given the lock is only used for insert and delete, I'm also not at
> all clear why you allocate 128 locks per cpu for very large tables.
> With the locks in their own array I don't think there can be 'false
> sharing', the worst than can happen is two cpus spinning on locks
> in the same cache line.

Personally I'm totally against Bucket locks.  If you have a
scalability problem you really need to solve them at a higher
level, e.g., multiqueue transmission in networking.  Bucket
locks are simply kicking the can down the road, it'll come back
to bite you sooner or later in terms of scalability.

So no I'm not going to waste my time fixing up something that
in my opinion shouldn't even exist :)

Cheers,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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