hackbench regression due to commit 9dfc6e68bfe6e
in [Kernel]
|
Prev: nvidia controller failed command, possibly related to SMART selftest (2.6.32)
Next: powernow-k8: Core Performance Boost and effective frequency support
From: Christoph Lameter on 22 Apr 2010 12:00 On Tue, 20 Apr 2010, Rafael J. Wysocki wrote: > The following bug entry is on the current list of known regressions > from 2.6.33. Please verify if it still should be listed and let the tracking team > know (either way). I have not been able to reproduce it so far. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 22 Apr 2010 13:30 Christoph Lameter wrote: > On Tue, 20 Apr 2010, Rafael J. Wysocki wrote: > >> The following bug entry is on the current list of known regressions >> from 2.6.33. Please verify if it still should be listed and let the tracking team >> know (either way). > > I have not been able to reproduce it so far. So what are our options? We can revert the SLUB conversion patch for now but I still can't see what's wrong with it... Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka J Enberg on 23 Apr 2010 15:20 On Thu, 22 Apr 2010, Pekka Enberg wrote: >>> The following bug entry is on the current list of known regressions >>> from 2.6.33. Please verify if it still should be listed and let the >>> tracking team >>> know (either way). >> >> I have not been able to reproduce it so far. > > So what are our options? We can revert the SLUB conversion patch for now but > I still can't see what's wrong with it... I haven't been able to reproduce this either on my Core 2 machine. Yanmin, does something like this help on your machines? I'm thinking false sharing with some other per-CPU data structure that happens to be put in same percpu slot as struct kmem_cache_cpu... Pekka diff --git a/mm/slub.c b/mm/slub.c index 7d6c8b1..d8159d6 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -2066,7 +2066,7 @@ init_kmem_cache_node(struct kmem_cache_node *n, struct kmem_cache *s) #endif } -static DEFINE_PER_CPU(struct kmem_cache_cpu, kmalloc_percpu[KMALLOC_CACHES]); +static DEFINE_PER_CPU_ALIGNED(struct kmem_cache_cpu, kmalloc_percpu[KMALLOC_CACHES]); static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags) { @@ -2077,7 +2077,7 @@ static inline int alloc_kmem_cache_cpus(struct kmem_cache *s, gfp_t flags) */ s->cpu_slab = kmalloc_percpu + (s - kmalloc_caches); else - s->cpu_slab = alloc_percpu(struct kmem_cache_cpu); + s->cpu_slab = __alloc_percpu(sizeof(struct kmem_cache_cpu), cache_line_size()); if (!s->cpu_slab) return 0; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Zhang, Yanmin on 26 Apr 2010 03:00 On Fri, 2010-04-23 at 22:18 +0300, Pekka J Enberg wrote: > On Thu, 22 Apr 2010, Pekka Enberg wrote: > >>> The following bug entry is on the current list of known regressions > >>> from 2.6.33. Please verify if it still should be listed and let the > >>> tracking team > >>> know (either way). > >> > >> I have not been able to reproduce it so far. > > > > So what are our options? We can revert the SLUB conversion patch for now but > > I still can't see what's wrong with it... I also don't know why. The original patch looks good. > > I haven't been able to reproduce this either on my Core 2 machine. Mostly, the regression exists on Nehalem machines. I suspect it's related to hyper-threading machine. > > Yanmin, does something like this help on your machines? A quick testing doesn't show any help. I did a new testing. After the machine boots, I hot remove 8 hyper-threading cpu which means last 8 are just cores. The regression between 2.6.33 and 2.6.34-rc becomes small. My opinion is we needn't revert the patch, but still keep an eye on it when testing other new RC kernel releases. One reason is volanoMark and netperf have no such regression. Is it ok? Yanmin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pekka Enberg on 26 Apr 2010 03:30
Hi Yanmin, On Mon, Apr 26, 2010 at 9:59 AM, Zhang, Yanmin <yanmin_zhang(a)linux.intel.com> wrote: >> I haven't been able to reproduce this either on my Core 2 machine. > Mostly, the regression exists on Nehalem machines. I suspect it's related to > hyper-threading machine. OK, so does anyone know why hyper-threading would change things for the per-CPU allocator? >> Yanmin, does something like this help on your machines? > A quick testing doesn't show any help. So it's unlikely to be false sharing, I suppose. > I did a new testing. After the machine boots, I hot remove 8 hyper-threading cpu > which means last 8 are just cores. The regression between 2.6.33 and 2.6.34-rc becomes > small. > > My opinion is we needn't revert the patch, but still keep an eye on it when testing other > new RC kernel releases. One reason is volanoMark and netperf have no such regression. > Is it ok? We need to get this fixed. In my experience, it's pretty common that slab regressions pop up only in one or few benchmarks. The problem is likely to pop up in some real-world workload where it's even more difficult to track down because basic CPU profiles don't pin-point the problem. Do we have some Intel CPU expert hanging around here that could enlighten me of the effects of hyper-threading on CPU caching? I also wonder why it's showing up with the new per-CPU allocator and not with the homebrewn one we had in SLUB previously. Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |