[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1109271109570.9569@router.home>
Date: Tue, 27 Sep 2011 11:13:13 -0500 (CDT)
From: Christoph Lameter <cl@...two.org>
To: Gilad Ben-Yossef <gilad@...yossef.com>
cc: Shaohua Li <shaohua.li@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Frederic Weisbecker <fweisbec@...il.com>,
Russell King <linux@....linux.org.uk>,
Chris Metcalf <cmetcalf@...era.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Pekka Enberg <penberg@...nel.org>,
Matt Mackall <mpm@...enic.com>
Subject: Re: [PATCH 4/5] mm: Only IPI CPUs to drain local pages if they
exist
On Tue, 27 Sep 2011, Gilad Ben-Yossef wrote:
> My hope is to come up with a way to do more code on the CPU doing the
> flush_all (which
> as you said is a rare and none performance critical code path anyway)
> and by that gain the ability
> to do the job without interrupting CPUs that do not need to flush
> their per cpu pages.
You may not need that for the kmem_cache_destroy(). At close time there
are no users left and no one should be accessing the cache anyways. You
could flush the whole shebang without IPIs.
Problem is that there is no guarantee that other processes will not still
try to access the cache. If you want to guarantee that then change some
settings in either struct kmem_cache or struct kmem_cache_cpu that makes
allocation and freeing impossible before flushing the per cpu pages.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists