From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>,
Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] the proposal of improve page reclaim by throttle
Date: Thu, 21 Feb 2008 15:18:35 +0530 [thread overview]
Message-ID: <47BD48F3.3040903@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080219134715.7E90.KOSAKI.MOTOHIRO@jp.fujitsu.com>
KOSAKI Motohiro wrote:
> background
> ========================================
> current VM implementation doesn't has limit of # of parallel reclaim.
> when heavy workload, it bring to 2 bad things
> - heavy lock contention
> - unnecessary swap out
>
> abount 2 month ago, KAMEZA Hiroyuki proposed the patch of page
> reclaim throttle and explain it improve reclaim time.
> http://marc.info/?l=linux-mm&m=119667465917215&w=2
>
> but unfortunately it works only memcgroup reclaim.
> Today, I implement it again for support global reclaim and mesure it.
>
Hi, Kosaki,
It's good to keep the main reclaim code and the memory controller reclaim in
sync, so this is a nice effort.
> @@ -1456,7 +1501,7 @@ unsigned long try_to_free_mem_cgroup_pag
> int target_zone = gfp_zone(GFP_HIGHUSER_MOVABLE);
>
> zones = NODE_DATA(numa_node_id())->node_zonelists[target_zone].zones;
> - if (do_try_to_free_pages(zones, sc.gfp_mask, &sc))
> + if (try_to_free_pages_throttled(zones, 0, sc.gfp_mask, &sc))
> return 1;
> return 0;
> }
>
try_to_free_pages_throttled checks for zone_watermark_ok(), that will not work
in the case that we are reclaiming from a cgroup which over it's limit. We need
a different check, to see if the mem_cgroup is still over it's limit or not.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2008-02-21 9:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-19 5:44 [RFC][PATCH] the proposal of improve page reclaim by throttle KOSAKI Motohiro
2008-02-19 6:34 ` Nick Piggin
2008-02-19 7:09 ` KOSAKI Motohiro
2008-02-19 13:31 ` Rik van Riel
2008-02-20 8:56 ` minchan Kim
2008-02-20 9:24 ` KOSAKI Motohiro
2008-02-20 9:49 ` minchan Kim
2008-02-20 10:09 ` KOSAKI Motohiro
2008-02-21 9:38 ` minchan Kim
2008-02-21 10:55 ` KOSAKI Motohiro
2008-02-21 12:29 ` minchan Kim
2008-02-21 12:41 ` KOSAKI Motohiro
2008-02-21 9:48 ` Balbir Singh [this message]
2008-02-21 11:01 ` KOSAKI Motohiro
2008-02-21 11:02 ` Balbir Singh
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=47BD48F3.3040903@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=Lee.Schermerhorn@hp.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=riel@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).