On Fri, Dec 30, 2011 at 10:29 PM, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > On Fri, Dec 30, 2011 at 6:08 PM, Mel Gorman <mgorman@xxxxxxx> 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@xxxxxxxxxxxxx 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, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href