lkml.org 
[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Bug #15713] hackbench regression due to commit 9dfc6e68bfe6e
Hello, Pekka.

On 04/26/2010 04:17 PM, Pekka J Enberg wrote:
> Even if the cacheline is dirtied like in the struct kmem_cache_cpu case?

If my hypothesis is the case, I don't think dirtying or not would
matter. It's about two cpus sharing a cache line which usually is a
bad idea but in this case happens to be a good idea because the two
cpus sit on the same cache.

> If that's the case, don't we want the per-CPU allocator to support back
> to back allocation for cores that are in the same package?

I think it's probably gonna be an over-engineering effort. W/ percpu
allocator the rest of the cacheline would likely be occupied by
another percpu item for the cpu, so it's not really wasted. It's just
used differently. It would be good if we have a way to better pack
small hot ones (for the same cpu) into the same cachelines but I don't
think it would be wise to interleave stuff from different cpus. It's
not like there's only single way to save a cacheline after all.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2010-04-26 16:37    [W:0.057 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site