Messages in this thread | | | Date | Sun, 13 Nov 2011 20:20:12 +0800 | Subject | Re: [PATCH v3 4/5] slub: Only IPI CPUs that have per cpu obj to flush | From | Hillf Danton <> |
| |
On Sun, Nov 13, 2011 at 6:17 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote: > flush_all() is called for each kmem_cahce_destroy(). So every cache > being destroyed dynamically ended up sending an IPI to each CPU in the > system, regardless if the cache has ever been used there. > > For example, if you close the Infinband ipath driver char device file, > the close file ops calls kmem_cache_destroy(). So running some > infiniband config tool on one a single CPU dedicated to system tasks > might interrupt the rest of the 127 CPUs I dedicated to some CPU > intensive task. > > I suspect there is a good chance that every line in the output of "git > grep kmem_cache_destroy linux/ | grep '\->'" has a similar scenario. > > This patch attempts to rectify this issue by sending an IPI to flush > the per cpu objects back to the free lists only to CPUs that seems to > have such objects. > > The check which CPU to IPI is racy but we don't care since asking a > CPU without per cpu objects to flush does no damage and as far as I > can tell the flush_all by itself is racy against allocs on remote > CPUs anyway, so if you meant the flush_all to be determinstic, you > had to arrange for locking regardless. > > Without this patch the following artificial test case: > > $ cd /sys/kernel/slab > $ for DIR in *; do cat $DIR/alloc_calls > /dev/null; done > > produces 166 IPIs on an cpuset isolated CPU. With it it produces none. > > The code path of memory allocation failure for CPUMASK_OFFSTACK=y > config was tested using fault injection framework. > > Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> > Acked-by: Chris Metcalf <cmetcalf@tilera.com> > CC: Peter Zijlstra <a.p.zijlstra@chello.nl> > CC: Frederic Weisbecker <fweisbec@gmail.com> > CC: Russell King <linux@arm.linux.org.uk> > CC: linux-mm@kvack.org > CC: Christoph Lameter <cl@linux-foundation.org> > CC: Pekka Enberg <penberg@kernel.org> > CC: Matt Mackall <mpm@selenic.com> > CC: Sasha Levin <levinsasha928@gmail.com> > CC: Rik van Riel <riel@redhat.com> > CC: Andi Kleen <andi@firstfloor.org> > --- > mm/slub.c | 15 ++++++++++++++- > 1 files changed, 14 insertions(+), 1 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index 7d2a996..caf4b3a 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -2006,7 +2006,20 @@ static void flush_cpu_slab(void *d) > > static void flush_all(struct kmem_cache *s) > { > - on_each_cpu(flush_cpu_slab, s, 1); > + cpumask_var_t cpus; > + struct kmem_cache_cpu *c; > + int cpu; > + > + if (likely(zalloc_cpumask_var(&cpus, GFP_ATOMIC))) {
Perhaps, the technique of local_cpu_mask defined in kernel/sched_rt.c could be used to replace the above atomic allocation.
Best regards
Hillf
> + for_each_online_cpu(cpu) { > + c = per_cpu_ptr(s->cpu_slab, cpu); > + if (c && c->page) > + cpumask_set_cpu(cpu, cpus); > + } > + on_each_cpu_mask(cpus, flush_cpu_slab, s, 1); > + free_cpumask_var(cpus); > + } else > + on_each_cpu(flush_cpu_slab, s, 1); > } > > /* > -- > 1.7.0.4 > > -- > 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/ > > > -- 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/
| |