On Mon, Mar 03, 2008 at 11:35:44PM +0200, Pekka Enberg wrote:
quoted text
> 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.


quoted text
> 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).
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/