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... Of course, it'll still cause a load of cache line bouncing, so maybe it's not worth it. > It would still be nice to have some data on how much IPIs are reduced > in practice to confirm the patch really helps. I agree. I'll prepare the patch and will present the data. Thanks! 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