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 18:06:53 +0200
From:	Gilad Ben-Yossef <>
To:	Michal Nazarewicz <>
Cc:	Marek Szyprowski <>,,,,,,
	Kyungmin Park <>,
	Russell King <>,
	Andrew Morton <>,
	KAMEZAWA Hiroyuki <>,
	Daniel Walker <>,
	Mel Gorman <>, Arnd Bergmann <>,
	Jesse Barker <>,
	Jonathan Corbet <>,
	Shariq Hasnain <>,
	Chunsang Jeong <>,
	Dave Hansen <>,
	Benjamin Gaignard <>
Subject: Re: [PATCH 01/11] mm: page_alloc: set_migratetype_isolate: drain PCP
 prior to isolating

2012/1/1 Michal Nazarewicz <>:
>> On Thu, Dec 29, 2011 at 2:39 PM, Marek Szyprowski
>> <> wrote:

> On Sun, 01 Jan 2012 08:49:13 +0100, Gilad Ben-Yossef <>
> wrote:
>> Please consider whether sending an IPI to all processors in the system
>> and interrupting them is appropriate here.
>> You seem to assume that it is probable that each CPU of the possibly
>> 4,096 (MAXSMP on x86) has a per-cpu page for the specified zone,
> I'm not really assuming that (in fact I expect what you fear, ie. that
> most CPUs won't have pages from specified zone an PCP list), however,
> I really need to make sure to get them off all PCP lists.

True, the question is whether or not you have to send a global IPI to do that.

>> otherwise you're just interrupting them out of doing something useful,
>> or save power idle for nothing.
> Exactly what's happening now anyway.


>> While that may or may not be a reasonable assumption for the general
>> drain_all_pages that drains pcps from all zones, I feel it is less
>> likely to be the right thing once you limit the drain to a single
>> zone.
> Currently, set_migratetype_isolate() seem to do more then it needs to,
> ie. it drains all the pages even though all it cares about is a single
> zone.

I agree your patch is better then current state. I just did want to add
yet another global IPI I'll have to chase afterwards.. :-)
>> Some background on my attempt to reduce "IPI noise" in the system in
>> this context is probably useful here as
>> well:
> Looks interesting, I'm not entirely sure why it does not end up a race
> condition, but in case of __zone_drain_all_pages() we already hold

If a page is in the PCP list when we check, you'll send the IPI and all is well.

If it isn't when we check and gets added later you could just the same have
situation where we send the IPI, try to do try an empty PCP list and then
the page gets added. So we are not adding a race condition that is not there
already :-)

> zone->lock, so my fears are somehow gone..  I'll give it a try, and prepare
> a patch for __zone_drain_all_pages().

I plan to send V5 of the IPI noise patch after some testing. It has a new
version of the drain_all_pages, with no allocation in the reclaim path
and no locking. You might want to wait till that one is out to base on it.

Thank you for considering my feedback :-)


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