linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: mgorman@suse.de
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] mm: page allocator: Initialise ZLC for first zone eligible for zone_reclaim
Date: Thu, 14 Jul 2011 10:20:12 +0900	[thread overview]
Message-ID: <4E1E444C.3090000@jp.fujitsu.com> (raw)
In-Reply-To: <20110713110246.GF7529@suse.de>

(2011/07/13 20:02), Mel Gorman wrote:
> On Wed, Jul 13, 2011 at 10:15:15AM +0900, KOSAKI Motohiro wrote:
>> (2011/07/11 22:01), Mel Gorman wrote:
>>> The zonelist cache (ZLC) is used among other things to record if
>>> zone_reclaim() failed for a particular zone recently. The intention
>>> is to avoid a high cost scanning extremely long zonelists or scanning
>>> within the zone uselessly.
>>>
>>> Currently the zonelist cache is setup only after the first zone has
>>> been considered and zone_reclaim() has been called. The objective was
>>> to avoid a costly setup but zone_reclaim is itself quite expensive. If
>>> it is failing regularly such as the first eligible zone having mostly
>>> mapped pages, the cost in scanning and allocation stalls is far higher
>>> than the ZLC initialisation step.
>>>
>>> This patch initialises ZLC before the first eligible zone calls
>>> zone_reclaim(). Once initialised, it is checked whether the zone
>>> failed zone_reclaim recently. If it has, the zone is skipped. As the
>>> first zone is now being checked, additional care has to be taken about
>>> zones marked full. A zone can be marked "full" because it should not
>>> have enough unmapped pages for zone_reclaim but this is excessive as
>>> direct reclaim or kswapd may succeed where zone_reclaim fails. Only
>>> mark zones "full" after zone_reclaim fails if it failed to reclaim
>>> enough pages after scanning.
>>>
>>> Signed-off-by: Mel Gorman <mgorman@suse.de>
>>
>> If I understand correctly this patch's procs/cons is,
>>
>> pros.
>>  1) faster when zone reclaim doesn't work effectively
>>
> 
> Yes.
> 
>> cons.
>>  2) slower when zone reclaim is off
> 
> How is it slower with zone_reclaim off?
> 
> Before
> 
> 	if (zone_reclaim_mode == 0)
> 		goto this_zone_full;
> 	...
> 	this_zone_full:
> 	if (NUMA_BUILD)
> 		zlc_mark_zone_full(zonelist, z);
> 	if (NUMA_BUILD && !did_zlc_setup && nr_online_nodes > 1) {
> 		...
> 	}
> 
> After
> 	if (NUMA_BUILD && !did_zlc_setup && nr_online_nodes > 1) {
> 		...
> 	}
> 	if (zone_reclaim_mode == 0)
> 		goto this_zone_full;
> 	this_zone_full:
> 	if (NUMA_BUILD)
> 		zlc_mark_zone_full(zonelist, z);
> 
> Bear in mind that if the watermarks are met on the first zone, the zlc
> setup does not occur.

Right you are. thank you correct me.


>>  3) slower when zone recliam works effectively
>>
> 
> Marginally slower. It's now calling zlc setup so once a second it's
> zeroing a bitmap and calling zlc_zone_worth_trying() on the first
> zone testing a bit on a cache-hot structure.
> 
> As the ineffective case can be triggered by a simple cp, I think the
> cost is justified. Can you think of a better way of doing this?

So, now I'm revisit your number in [0/3]. and I've conclude your patch
improve simple cp case too. then please forget my last mail. this patch
looks nicer.

	Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>


> 
>> (2) and (3) are frequently happen than (1), correct?
> 
> Yes. I'd still expect zone_reclaim to be off on the majority of
> machines and even when enabled, I think it's relatively rare we hit the
> case where the workload is regularly falling over to the other node
> except in the case where it's a file server. Still, a cp is not to
> uncommon that the kernel should slow to a crawl as a result.
> 
>> At least, I think we need to keep zero impact when zone reclaim mode is off.
>>
> 
> I agree with this but I'm missing where we are taking the big hit with
> zone_reclaim==0.
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  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=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-07-14  1:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-11 13:01 [RFC PATCH 0/3] Reduce frequency of stalls due to zone_reclaim() on NUMA Mel Gorman
2011-07-11 13:01 ` [PATCH 1/3] mm: vmscan: Do use use PF_SWAPWRITE from zone_reclaim Mel Gorman
2011-07-12  9:27   ` Minchan Kim
2011-07-12  9:40     ` KOSAKI Motohiro
2011-07-12  9:55       ` Minchan Kim
2011-07-12 15:43         ` Christoph Lameter
2011-07-13 10:40           ` Mel Gorman
2011-07-12 10:14       ` Mel Gorman
2011-07-13  0:34         ` KOSAKI Motohiro
2011-07-11 13:01 ` [PATCH 2/3] mm: page allocator: Initialise ZLC for first zone eligible for zone_reclaim Mel Gorman
2011-07-13  1:15   ` KOSAKI Motohiro
2011-07-13 11:02     ` Mel Gorman
2011-07-14  1:20       ` KOSAKI Motohiro [this message]
2011-07-14  6:11         ` Mel Gorman
2011-07-11 13:01 ` [PATCH 3/3] mm: page allocator: Reconsider zones for allocation after direct reclaim Mel Gorman
2011-07-13  0:42   ` KOSAKI Motohiro
2011-07-13 11:10     ` Mel Gorman
2011-07-14  3:20       ` KOSAKI Motohiro
2011-07-14  6:10         ` Mel Gorman
2011-07-21  9:35           ` KOSAKI Motohiro
2011-07-21 10:31             ` Mel Gorman
2011-07-15 14:59 [PATCH 0/2] Reduce frequency of stalls due to zone_reclaim() on NUMA v2 Mel Gorman
2011-07-15 14:59 ` [PATCH 2/3] mm: page allocator: Initialise ZLC for first zone eligible for zone_reclaim Mel Gorman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E1E444C.3090000@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox