From: Simon Jeons <simon.jeons@gmail.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Hedi Berriche <hedi@sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: page_alloc: Avoid marking zones full prematurely after zone_reclaim()
Date: Thu, 21 Mar 2013 10:33:07 +0800 [thread overview]
Message-ID: <514A7163.5070700@gmail.com> (raw)
In-Reply-To: <20130320181957.GA1878@suse.de>
Hi Mel,
On 03/21/2013 02:19 AM, Mel Gorman wrote:
> The following problem was reported against a distribution kernel when
> zone_reclaim was enabled but the same problem applies to the mainline
> kernel. The reproduction case was as follows
>
> 1. Run numactl -m +0 dd if=largefile of=/dev/null
> This allocates a large number of clean pages in node 0
I confuse why this need allocate a large number of clean pages?
>
> 2. numactl -N +0 memhog 0.5*Mg
> This start a memory-using application in node 0.
>
> The expected behaviour is that the clean pages get reclaimed and the
> application uses node 0 for its memory. The observed behaviour was that
> the memory for the memhog application was allocated off-node since commits
> cd38b11 (mm: page allocator: initialise ZLC for first zone eligible for
> zone_reclaim) and commit 76d3fbf (mm: page allocator: reconsider zones
> for allocation after direct reclaim).
>
> The assumption of those patches was that it was always preferable to
> allocate quickly than stall for long periods of time and they were
> meant to take care that the zone was only marked full when necessary but
> an important case was missed.
>
> In the allocator fast path, only the low watermarks are checked. If the
> zones free pages are between the low and min watermark then allocations
> from the allocators slow path will succeed. However, zone_reclaim
> will only reclaim SWAP_CLUSTER_MAX or 1<<order pages. There is no
> guarantee that this will meet the low watermark causing the zone to be
> marked full prematurely.
>
> This patch will only mark the zone full after zone_reclaim if it the min
> watermarks are checked or if page reclaim failed to make sufficient
> progress.
>
> Reported-and-tested-by: Hedi Berriche <hedi@sgi.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> mm/page_alloc.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8fcced7..adce823 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1940,9 +1940,24 @@ zonelist_scan:
> continue;
> default:
> /* did we reclaim enough */
> - if (!zone_watermark_ok(zone, order, mark,
> + if (zone_watermark_ok(zone, order, mark,
> classzone_idx, alloc_flags))
> + goto try_this_zone;
> +
> + /*
> + * Failed to reclaim enough to meet watermark.
> + * Only mark the zone full if checking the min
> + * watermark or if we failed to reclaim just
> + * 1<<order pages or else the page allocator
> + * fastpath will prematurely mark zones full
> + * when the watermark is between the low and
> + * min watermarks.
> + */
> + if ((alloc_flags & ALLOC_WMARK_MIN) ||
> + ret == ZONE_RECLAIM_SOME)
> goto this_zone_full;
> +
> + continue;
> }
> }
>
>
> --
> 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>
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Jeons <simon.jeons@gmail.com>
To: Mel Gorman <mgorman@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michal Hocko <mhocko@suse.cz>, Hedi Berriche <hedi@sgi.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: page_alloc: Avoid marking zones full prematurely after zone_reclaim()
Date: Thu, 21 Mar 2013 10:33:07 +0800 [thread overview]
Message-ID: <514A7163.5070700@gmail.com> (raw)
In-Reply-To: <20130320181957.GA1878@suse.de>
Hi Mel,
On 03/21/2013 02:19 AM, Mel Gorman wrote:
> The following problem was reported against a distribution kernel when
> zone_reclaim was enabled but the same problem applies to the mainline
> kernel. The reproduction case was as follows
>
> 1. Run numactl -m +0 dd if=largefile of=/dev/null
> This allocates a large number of clean pages in node 0
I confuse why this need allocate a large number of clean pages?
>
> 2. numactl -N +0 memhog 0.5*Mg
> This start a memory-using application in node 0.
>
> The expected behaviour is that the clean pages get reclaimed and the
> application uses node 0 for its memory. The observed behaviour was that
> the memory for the memhog application was allocated off-node since commits
> cd38b11 (mm: page allocator: initialise ZLC for first zone eligible for
> zone_reclaim) and commit 76d3fbf (mm: page allocator: reconsider zones
> for allocation after direct reclaim).
>
> The assumption of those patches was that it was always preferable to
> allocate quickly than stall for long periods of time and they were
> meant to take care that the zone was only marked full when necessary but
> an important case was missed.
>
> In the allocator fast path, only the low watermarks are checked. If the
> zones free pages are between the low and min watermark then allocations
> from the allocators slow path will succeed. However, zone_reclaim
> will only reclaim SWAP_CLUSTER_MAX or 1<<order pages. There is no
> guarantee that this will meet the low watermark causing the zone to be
> marked full prematurely.
>
> This patch will only mark the zone full after zone_reclaim if it the min
> watermarks are checked or if page reclaim failed to make sufficient
> progress.
>
> Reported-and-tested-by: Hedi Berriche <hedi@sgi.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
> ---
> mm/page_alloc.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8fcced7..adce823 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1940,9 +1940,24 @@ zonelist_scan:
> continue;
> default:
> /* did we reclaim enough */
> - if (!zone_watermark_ok(zone, order, mark,
> + if (zone_watermark_ok(zone, order, mark,
> classzone_idx, alloc_flags))
> + goto try_this_zone;
> +
> + /*
> + * Failed to reclaim enough to meet watermark.
> + * Only mark the zone full if checking the min
> + * watermark or if we failed to reclaim just
> + * 1<<order pages or else the page allocator
> + * fastpath will prematurely mark zones full
> + * when the watermark is between the low and
> + * min watermarks.
> + */
> + if ((alloc_flags & ALLOC_WMARK_MIN) ||
> + ret == ZONE_RECLAIM_SOME)
> goto this_zone_full;
> +
> + continue;
> }
> }
>
>
> --
> 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:[~2013-03-21 2:33 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-20 18:19 [PATCH] mm: page_alloc: Avoid marking zones full prematurely after zone_reclaim() Mel Gorman
2013-03-20 18:19 ` Mel Gorman
2013-03-20 18:45 ` Michal Hocko
2013-03-20 18:45 ` Michal Hocko
2013-03-21 2:32 ` Wanpeng Li
2013-03-21 2:32 ` Wanpeng Li
2013-03-21 2:33 ` Simon Jeons [this message]
2013-03-21 2:33 ` Simon Jeons
2013-03-21 8:19 ` Michal Hocko
2013-03-21 8:19 ` Michal Hocko
2013-03-21 8:32 ` Simon Jeons
2013-03-21 8:32 ` Simon Jeons
2013-03-21 8:44 ` Michal Hocko
2013-03-21 8:44 ` Michal Hocko
2013-03-21 8:59 ` Wanpeng Li
2013-03-21 8:59 ` Wanpeng Li
2013-04-05 6:31 ` Simon Jeons
2013-04-05 6:31 ` Simon Jeons
2013-04-07 6:37 ` Simon Jeons
2013-04-07 6:37 ` Simon Jeons
2013-04-09 10:05 ` Simon Jeons
2013-04-09 10:05 ` Simon Jeons
2013-04-09 10:14 ` Michal Hocko
2013-04-09 10:14 ` Michal Hocko
2013-04-09 10:20 ` Simon Jeons
2013-04-09 10:20 ` Simon Jeons
2013-04-10 5:15 ` Ric Mason
2013-04-10 5:15 ` Ric Mason
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=514A7163.5070700@gmail.com \
--to=simon.jeons@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=hedi@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.cz \
/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.