Messages in this thread | | | Date | Wed, 5 Mar 2008 01:28:21 +0100 | From | Nick Piggin <> | Subject | Re: [rfc][patch 1/3] slub: fix small HWCACHE_ALIGN alignment |
| |
On Mon, Mar 03, 2008 at 11:35:44PM +0200, Pekka Enberg wrote: > Hi, > > Christoph Lameter wrote: > >Well the guarantee can only be exploited if you would check the cacheline > >sizes and the object size from the code that creates the slab cache. > >Basically you would have to guestimate what the slab allocator is doing. > > > >So the guarantee is basically meaningless. If the object is larger than a > >cacheline then this will never work. > > Yes, I know that. That's why I am asking why this matters. If there's > some sort of regression because SLUB does HWCACHE_ALIGN bit differently, > we need to fix that.
It started out as a SLUB regression that was exposing poor code in the percpu allocator due to different SLUB kmalloc alignments. That prompted some further investigation about the alignment handling in the allocators and showed up this problem with SLUB's HWCACHE_ALIGN. While I don't know of a regression caused by it as such, it is totally unreasonable to just change the semantics of it (seemingly for no good reason). It is used quite a bit in networking for one, and those guys count every single cache miss in their fastpaths.
> Not that it necessarily means we have to change > HWCACHE_ALIGN but I am assuming Nick has some reason why he wants to > introduce the SMP alignment flag.
The SMP flag was just an RFC. I think some people (like Christoph) were being confused about the HWCACHE_ALIGN flag being for avoiding false sharing on SMP systems. It would actually be also generally useful to have the SMP flag (eg. see the sites I added it to in patch #3).
| |