From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Chris Webb <chris@arachsys.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: Over-eager swapping
Date: Tue, 3 Aug 2010 14:39:29 +0800 [thread overview]
Message-ID: <20100803063929.GB17955@localhost> (raw)
In-Reply-To: <AANLkTimC1z0MwTxUjxED7N1-R4D_YXtvnPSbiKXdR+4W@mail.gmail.com>
On Tue, Aug 03, 2010 at 12:47:36PM +0800, Minchan Kim wrote:
> On Tue, Aug 3, 2010 at 1:28 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > On Tue, Aug 03, 2010 at 12:09:18PM +0800, Minchan Kim wrote:
> >> On Tue, Aug 3, 2010 at 12:31 PM, Chris Webb <chris@arachsys.com> wrote:
> >> > Minchan Kim <minchan.kim@gmail.com> writes:
> >> >
> >> >> Another possibility is _zone_reclaim_ in NUMA.
> >> >> Your working set has many anonymous page.
> >> >>
> >> >> The zone_reclaim set priority to ZONE_RECLAIM_PRIORITY.
> >> >> It can make reclaim mode to lumpy so it can page out anon pages.
> >> >>
> >> >> Could you show me /proc/sys/vm/[zone_reclaim_mode/min_unmapped_ratio] ?
> >> >
> >> > Sure, no problem. On the machine with the /proc/meminfo I showed earlier,
> >> > these are
> >> >
> >> > # cat /proc/sys/vm/zone_reclaim_mode
> >> > 0
> >> > # cat /proc/sys/vm/min_unmapped_ratio
> >> > 1
> >>
> >> if zone_reclaim_mode is zero, it doesn't swap out anon_pages.
> >
> > If there are lots of order-1 or higher allocations, anonymous pages
> > will be randomly evicted, regardless of their LRU ages. This is
>
> I thought swapped out page is huge (ie, 3G) even though it enters lumpy mode.
> But it's possible. :)
>
> > probably another factor why the users claim. Are there easy ways to
> > confirm this other than patching the kernel?
>
> cat /proc/buddyinfo can help?
Some high order slab caches may show up there :)
> Off-topic:
> It would be better to add new vmstat of lumpy entrance.
I think it's a good debug entry. Although convenient, lumpy reclaim
is accompanied with some bad side effects. When something goes wrong,
it helps to check the number of lumpy reclaims.
Thanks,
Fengguang
> Pseudo code.
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 0f9f624..d10ff4e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1641,7 +1641,7 @@ out:
> }
> }
>
> -static void set_lumpy_reclaim_mode(int priority, struct scan_control *sc)
> +static void set_lumpy_reclaim_mode(int priority, struct scan_control
> *sc, struct zone *zone)
> {
> /*
> * If we need a large contiguous chunk of memory, or have
> @@ -1654,6 +1654,9 @@ static void set_lumpy_reclaim_mode(int priority,
> struct scan_control *sc)
> sc->lumpy_reclaim_mode = 1;
> else
> sc->lumpy_reclaim_mode = 0;
> +
> + if (sc->lumpy_reclaim_mode)
> + inc_zone_state(zone, NR_LUMPY);
> }
>
> /*
> @@ -1670,7 +1673,7 @@ static void shrink_zone(int priority, struct zone *zone,
>
> get_scan_count(zone, sc, nr, priority);
>
> - set_lumpy_reclaim_mode(priority, sc);
> + set_lumpy_reclaim_mode(priority, sc, zone);
>
> while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
> nr[LRU_INACTIVE_FILE]) {
>
> --
> Kind regards,
> Minchan Kim
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Chris Webb <chris@arachsys.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Subject: Re: Over-eager swapping
Date: Tue, 3 Aug 2010 14:39:29 +0800 [thread overview]
Message-ID: <20100803063929.GB17955@localhost> (raw)
In-Reply-To: <AANLkTimC1z0MwTxUjxED7N1-R4D_YXtvnPSbiKXdR+4W@mail.gmail.com>
On Tue, Aug 03, 2010 at 12:47:36PM +0800, Minchan Kim wrote:
> On Tue, Aug 3, 2010 at 1:28 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > On Tue, Aug 03, 2010 at 12:09:18PM +0800, Minchan Kim wrote:
> >> On Tue, Aug 3, 2010 at 12:31 PM, Chris Webb <chris@arachsys.com> wrote:
> >> > Minchan Kim <minchan.kim@gmail.com> writes:
> >> >
> >> >> Another possibility is _zone_reclaim_ in NUMA.
> >> >> Your working set has many anonymous page.
> >> >>
> >> >> The zone_reclaim set priority to ZONE_RECLAIM_PRIORITY.
> >> >> It can make reclaim mode to lumpy so it can page out anon pages.
> >> >>
> >> >> Could you show me /proc/sys/vm/[zone_reclaim_mode/min_unmapped_ratio] ?
> >> >
> >> > Sure, no problem. On the machine with the /proc/meminfo I showed earlier,
> >> > these are
> >> >
> >> > A # cat /proc/sys/vm/zone_reclaim_mode
> >> > A 0
> >> > A # cat /proc/sys/vm/min_unmapped_ratio
> >> > A 1
> >>
> >> if zone_reclaim_mode is zero, it doesn't swap out anon_pages.
> >
> > If there are lots of order-1 or higher allocations, anonymous pages
> > will be randomly evicted, regardless of their LRU ages. This is
>
> I thought swapped out page is huge (ie, 3G) even though it enters lumpy mode.
> But it's possible. :)
>
> > probably another factor why the users claim. Are there easy ways to
> > confirm this other than patching the kernel?
>
> cat /proc/buddyinfo can help?
Some high order slab caches may show up there :)
> Off-topic:
> It would be better to add new vmstat of lumpy entrance.
I think it's a good debug entry. Although convenient, lumpy reclaim
is accompanied with some bad side effects. When something goes wrong,
it helps to check the number of lumpy reclaims.
Thanks,
Fengguang
> Pseudo code.
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 0f9f624..d10ff4e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1641,7 +1641,7 @@ out:
> }
> }
>
> -static void set_lumpy_reclaim_mode(int priority, struct scan_control *sc)
> +static void set_lumpy_reclaim_mode(int priority, struct scan_control
> *sc, struct zone *zone)
> {
> /*
> * If we need a large contiguous chunk of memory, or have
> @@ -1654,6 +1654,9 @@ static void set_lumpy_reclaim_mode(int priority,
> struct scan_control *sc)
> sc->lumpy_reclaim_mode = 1;
> else
> sc->lumpy_reclaim_mode = 0;
> +
> + if (sc->lumpy_reclaim_mode)
> + inc_zone_state(zone, NR_LUMPY);
> }
>
> /*
> @@ -1670,7 +1673,7 @@ static void shrink_zone(int priority, struct zone *zone,
>
> get_scan_count(zone, sc, nr, priority);
>
> - set_lumpy_reclaim_mode(priority, sc);
> + set_lumpy_reclaim_mode(priority, sc, zone);
>
> while (nr[LRU_INACTIVE_ANON] || nr[LRU_ACTIVE_FILE] ||
> nr[LRU_INACTIVE_FILE]) {
>
> --
> Kind regards,
> Minchan Kim
--
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:[~2010-08-03 6:39 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 12:47 Over-eager swapping Chris Webb
2010-08-02 12:47 ` Chris Webb
2010-08-02 23:55 ` Minchan Kim
2010-08-02 23:55 ` Minchan Kim
2010-08-03 3:31 ` Chris Webb
2010-08-03 3:31 ` Chris Webb
2010-08-03 4:09 ` Minchan Kim
2010-08-03 4:09 ` Minchan Kim
2010-08-03 4:28 ` Wu Fengguang
2010-08-03 4:28 ` Wu Fengguang
2010-08-03 4:47 ` Minchan Kim
2010-08-03 4:47 ` Minchan Kim
2010-08-03 6:39 ` Wu Fengguang [this message]
2010-08-03 6:39 ` Wu Fengguang
2010-08-03 21:49 ` Chris Webb
2010-08-03 21:49 ` Chris Webb
2010-08-04 2:21 ` Wu Fengguang
2010-08-04 2:21 ` Wu Fengguang
2010-08-04 3:10 ` Minchan Kim
2010-08-04 3:24 ` Wu Fengguang
2010-08-04 3:24 ` Wu Fengguang
2010-08-04 9:58 ` Chris Webb
2010-08-04 9:58 ` Chris Webb
2010-08-04 11:49 ` Wu Fengguang
2010-08-04 11:49 ` Wu Fengguang
2010-08-04 12:04 ` Chris Webb
2010-08-04 12:04 ` Chris Webb
2010-08-18 14:38 ` Wu Fengguang
2010-08-18 14:38 ` Wu Fengguang
2010-08-18 14:46 ` Chris Webb
2010-08-18 14:46 ` Chris Webb
2010-08-18 15:21 ` Wu Fengguang
2010-08-18 15:21 ` Wu Fengguang
2010-08-18 15:57 ` Christoph Lameter
2010-08-18 15:57 ` Christoph Lameter
2010-08-18 16:20 ` Wu Fengguang
2010-08-18 16:20 ` Wu Fengguang
2010-08-18 15:57 ` Lee Schermerhorn
2010-08-18 15:57 ` Lee Schermerhorn
2010-08-18 15:58 ` Chris Webb
2010-08-18 15:58 ` Chris Webb
2010-08-18 16:13 ` Christoph Lameter
2010-08-18 16:13 ` Christoph Lameter
2010-08-18 16:32 ` Chris Webb
2010-08-18 16:32 ` Chris Webb
2010-08-19 5:16 ` Balbir Singh
2010-08-19 5:16 ` Balbir Singh
2010-08-19 10:20 ` Chris Webb
2010-08-19 10:20 ` Chris Webb
2010-08-19 19:03 ` Christoph Lameter
2010-08-19 19:03 ` Christoph Lameter
2010-08-18 16:13 ` Wu Fengguang
2010-08-18 16:13 ` Wu Fengguang
2010-08-18 16:31 ` Chris Webb
2010-08-18 16:31 ` Chris Webb
2010-08-19 5:13 ` Balbir Singh
2010-08-19 5:13 ` Balbir Singh
2010-08-18 16:45 ` Balbir Singh
2010-08-18 16:45 ` Balbir Singh
2010-08-19 9:25 ` Chris Webb
2010-08-19 9:25 ` Chris Webb
2010-08-19 15:13 ` Balbir Singh
2010-08-19 15:13 ` Balbir Singh
-- strict thread matches above, loose matches on Subject: below --
2012-04-23 9:27 Richard Davies
2012-04-23 9:27 ` Richard Davies
2012-04-23 12:07 ` Zdenek Kaspar
2012-04-23 12:07 ` Zdenek Kaspar
2012-04-23 17:19 ` Dave Hansen
2012-04-23 17:19 ` Dave Hansen
2012-04-24 0:35 ` Minchan Kim
2012-04-24 0:35 ` Minchan Kim
2012-04-24 11:16 ` Peter Lieven
2012-04-24 11:16 ` Peter Lieven
2012-04-25 14:41 ` Rik van Riel
2012-04-25 14:41 ` Rik van Riel
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=20100803063929.GB17955@localhost \
--to=fengguang.wu@intel.com \
--cc=chris@arachsys.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.