lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 1 Jan 2012 10:03:42 +0200
From:	Gilad Ben-Yossef <>
To:	Mel Gorman <>, Chris Metcalf <>
	Peter Zijlstra <>,
	Frederic Weisbecker <>,
	Russell King <>,,
	Pekka Enberg <>,
	Matt Mackall <>,
	Sasha Levin <>,
	Rik van Riel <>,
	Andi Kleen <>
Subject: Re: [PATCH v4 5/5] mm: Only IPI CPUs to drain local pages if they exist

On Fri, Dec 30, 2011 at 10:29 PM, Gilad Ben-Yossef <> wrote:
> On Fri, Dec 30, 2011 at 6:08 PM, Mel Gorman <> 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 Ben-Yossef
Chief Coffee Drinker
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388

"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
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists