Messages in this thread | | | Date | Sun, 1 Jan 2012 10:03:42 +0200 | Subject | Re: [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they exist | From | Gilad Ben-Yossef <> |
| |
On Fri, Dec 30, 2011 at 10:29 PM, Gilad Ben-Yossef <gilad@benyossef.com> wrote: > On Fri, Dec 30, 2011 at 6:08 PM, Mel Gorman <mgorman@suse.de> wrote: >> On Fri, Dec 30, 2011 at 10:25:46AM -0500, Chris Metcalf wrote: > >>> Alternately, since we really don't want more than one cpu running the drain >>> code anyway, you could imagine using a static cpumask, along with a lock to >>> serialize attempts to drain all the pages. (Locking here would be tricky, >>> since we need to run on_each_cpu with interrupts enabled, but there's >>> probably some reasonable way to make it work.) >>> >> >> Good suggestion, that would at least shut up my complaining >> about allocation costs! A statically-declared mutex similar >> to hugetlb_instantiation_mutex should do it. The context that >> drain_all_pages is called from will have interrupts enabled. >> >> Serialising processes entering direct reclaim may result in some stalls >> but overall I think the impact of that would be less than increasing >> memory pressure when low on memory. >> > > Chris, I like the idea :-) > > Actually, assuming for a second that on_each_cpu* and underlying code > wont mind if the cpumask will change mid call (I know it does, just thinking out > loud), you could say you don't even need the lock if you careful in how you > set/unset the per cpu bits of the cpumask, since they track the same thing...
I took a look and smp_call_function_many is actually fine with the passed cpumask getting changed in mid call.
I think this means we can do away with a single global cpumask without any locking and the cost becomes the allocation space for the single cpumask and the cache bouncing for concurrent updating of the cpumask if drain_all_pages races against itself on other cpus.
I'll spin a patch based on this idea.
Happy new year :-) Gilad
-- Gilad Ben-Yossef Chief Coffee Drinker gilad@benyossef.com Israel Cell: +972-52-8260388 US Cell: +1-973-8260388 http://benyossef.com
"Unfortunately, cache misses are an equal opportunity pain provider." -- Mike Galbraith, 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/
| |