Re: [v1 PATCH 9/10] rhashtable: Allow GFP_ATOMIC bucket table allocation
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: 2015-03-24 03:09:43
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 [off-list ref] Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt