From: Wu Fengguang <fengguang.wu@intel.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
"Zhang, Yanmin" <yanmin.zhang@intel.com>,
"linuxram@us.ibm.com" <linuxram@us.ibm.com>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] Do not unconditionally treat zones that fail zone_reclaim() as full
Date: Tue, 9 Jun 2009 11:11:19 +0800 [thread overview]
Message-ID: <20090609031119.GB7875@localhost> (raw)
In-Reply-To: <1244466090-10711-4-git-send-email-mel@csn.ul.ie>
On Mon, Jun 08, 2009 at 09:01:30PM +0800, Mel Gorman wrote:
> On NUMA machines, the administrator can configure zone_reclaim_mode that
> is a more targetted form of direct reclaim. On machines with large NUMA
> distances for example, a zone_reclaim_mode defaults to 1 meaning that clean
> unmapped pages will be reclaimed if the zone watermarks are not being
> met. The problem is that zone_reclaim() failing at all means the zone
> gets marked full.
>
> This can cause situations where a zone is usable, but is being skipped
> because it has been considered full. Take a situation where a large tmpfs
> mount is occuping a large percentage of memory overall. The pages do not
> get cleaned or reclaimed by zone_reclaim(), but the zone gets marked full
> and the zonelist cache considers them not worth trying in the future.
>
> This patch makes zone_reclaim() return more fine-grained information about
> what occured when zone_reclaim() failued. The zone only gets marked full if
> it really is unreclaimable. If it's a case that the scan did not occur or
> if enough pages were not reclaimed with the limited reclaim_mode, then the
> zone is simply skipped.
>
> There is a side-effect to this patch. Currently, if zone_reclaim()
> successfully reclaimed SWAP_CLUSTER_MAX, an allocation attempt would
> go ahead. With this patch applied, zone watermarks are rechecked after
> zone_reclaim() does some work.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Thanks for making the code a lot more readable :)
Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
> /*
> * Do not scan if the allocation should not be delayed.
> */
> if (!(gfp_mask & __GFP_WAIT) || (current->flags & PF_MEMALLOC))
> - return 0;
> + return ZONE_RECLAIM_NOSCAN;
Why not kill the extra tab?
WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
Rik van Riel <riel@redhat.com>,
Christoph Lameter <cl@linux-foundation.org>,
"Zhang, Yanmin" <yanmin.zhang@intel.com>,
"linuxram@us.ibm.com" <linuxram@us.ibm.com>,
linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] Do not unconditionally treat zones that fail zone_reclaim() as full
Date: Tue, 9 Jun 2009 11:11:19 +0800 [thread overview]
Message-ID: <20090609031119.GB7875@localhost> (raw)
In-Reply-To: <1244466090-10711-4-git-send-email-mel@csn.ul.ie>
On Mon, Jun 08, 2009 at 09:01:30PM +0800, Mel Gorman wrote:
> On NUMA machines, the administrator can configure zone_reclaim_mode that
> is a more targetted form of direct reclaim. On machines with large NUMA
> distances for example, a zone_reclaim_mode defaults to 1 meaning that clean
> unmapped pages will be reclaimed if the zone watermarks are not being
> met. The problem is that zone_reclaim() failing at all means the zone
> gets marked full.
>
> This can cause situations where a zone is usable, but is being skipped
> because it has been considered full. Take a situation where a large tmpfs
> mount is occuping a large percentage of memory overall. The pages do not
> get cleaned or reclaimed by zone_reclaim(), but the zone gets marked full
> and the zonelist cache considers them not worth trying in the future.
>
> This patch makes zone_reclaim() return more fine-grained information about
> what occured when zone_reclaim() failued. The zone only gets marked full if
> it really is unreclaimable. If it's a case that the scan did not occur or
> if enough pages were not reclaimed with the limited reclaim_mode, then the
> zone is simply skipped.
>
> There is a side-effect to this patch. Currently, if zone_reclaim()
> successfully reclaimed SWAP_CLUSTER_MAX, an allocation attempt would
> go ahead. With this patch applied, zone watermarks are rechecked after
> zone_reclaim() does some work.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Thanks for making the code a lot more readable :)
Reviewed-by: Wu Fengguang <fengguang.wu@intel.com>
> /*
> * Do not scan if the allocation should not be delayed.
> */
> if (!(gfp_mask & __GFP_WAIT) || (current->flags & PF_MEMALLOC))
> - return 0;
> + return ZONE_RECLAIM_NOSCAN;
Why not kill the extra tab?
--
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:[~2009-06-09 3:14 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-08 13:01 [PATCH 0/3] [RFC] Functional fix to zone_reclaim() and bring behaviour more in line with expectations Mel Gorman
2009-06-08 13:01 ` Mel Gorman
2009-06-08 13:01 ` [PATCH 1/3] Reintroduce zone_reclaim_interval for when zone_reclaim() scans and fails to avoid CPU spinning at 100% on NUMA Mel Gorman
2009-06-08 13:01 ` Mel Gorman
2009-06-08 13:31 ` Rik van Riel
2009-06-08 13:31 ` Rik van Riel
2009-06-08 13:54 ` Mel Gorman
2009-06-08 13:54 ` Mel Gorman
2009-06-08 14:33 ` Christoph Lameter
2009-06-08 14:33 ` Christoph Lameter
2009-06-08 14:38 ` Mel Gorman
2009-06-08 14:38 ` Mel Gorman
2009-06-08 14:55 ` Christoph Lameter
2009-06-08 14:55 ` Christoph Lameter
2009-06-08 15:11 ` Mel Gorman
2009-06-08 15:11 ` Mel Gorman
2009-06-10 5:23 ` Andrew Morton
2009-06-10 5:23 ` Andrew Morton
2009-06-10 6:44 ` KOSAKI Motohiro
2009-06-10 6:44 ` KOSAKI Motohiro
2009-06-10 10:00 ` Mel Gorman
2009-06-10 10:00 ` Mel Gorman
2009-06-08 14:48 ` Rik van Riel
2009-06-08 14:48 ` Rik van Riel
2009-06-09 8:08 ` Mel Gorman
2009-06-09 8:08 ` Mel Gorman
2009-06-09 1:58 ` Wu Fengguang
2009-06-09 1:58 ` Wu Fengguang
2009-06-09 8:14 ` Mel Gorman
2009-06-09 8:14 ` Mel Gorman
2009-06-09 8:25 ` Wu Fengguang
2009-06-09 8:25 ` Wu Fengguang
2009-06-09 8:31 ` Mel Gorman
2009-06-09 8:31 ` Mel Gorman
2009-06-09 9:07 ` Wu Fengguang
2009-06-09 9:07 ` Wu Fengguang
2009-06-09 9:40 ` Mel Gorman
2009-06-09 9:40 ` Mel Gorman
2009-06-09 13:38 ` Wu Fengguang
2009-06-09 13:38 ` Wu Fengguang
2009-06-09 15:06 ` Mel Gorman
2009-06-09 15:06 ` Mel Gorman
2009-06-10 2:14 ` Wu Fengguang
2009-06-10 2:14 ` Wu Fengguang
2009-06-10 9:54 ` Mel Gorman
2009-06-10 9:54 ` Mel Gorman
2009-06-09 7:48 ` KOSAKI Motohiro
2009-06-09 7:48 ` KOSAKI Motohiro
2009-06-09 8:18 ` Mel Gorman
2009-06-09 8:18 ` Mel Gorman
2009-06-09 8:45 ` KOSAKI Motohiro
2009-06-09 8:45 ` KOSAKI Motohiro
2009-06-09 9:42 ` Mel Gorman
2009-06-09 9:42 ` Mel Gorman
2009-06-09 9:45 ` KOSAKI Motohiro
2009-06-09 9:45 ` KOSAKI Motohiro
2009-06-09 9:59 ` KOSAKI Motohiro
2009-06-09 9:59 ` KOSAKI Motohiro
2009-06-09 10:44 ` Mel Gorman
2009-06-09 10:44 ` Mel Gorman
2009-06-09 10:50 ` KOSAKI Motohiro
2009-06-09 10:50 ` KOSAKI Motohiro
2009-06-08 13:01 ` [PATCH 2/3] Properly account for the number of page cache pages zone_reclaim() can reclaim Mel Gorman
2009-06-08 13:01 ` Mel Gorman
2009-06-08 14:25 ` Christoph Lameter
2009-06-08 14:25 ` Christoph Lameter
2009-06-08 14:36 ` Mel Gorman
2009-06-08 14:36 ` Mel Gorman
2009-06-09 2:25 ` Wu Fengguang
2009-06-09 2:25 ` Wu Fengguang
2009-06-09 8:27 ` Mel Gorman
2009-06-09 8:27 ` Mel Gorman
2009-06-09 8:45 ` Wu Fengguang
2009-06-09 8:45 ` Wu Fengguang
2009-06-09 10:48 ` Mel Gorman
2009-06-09 10:48 ` Mel Gorman
2009-06-09 12:08 ` Wu Fengguang
2009-06-09 12:08 ` Wu Fengguang
2009-06-09 8:55 ` KOSAKI Motohiro
2009-06-09 8:55 ` KOSAKI Motohiro
2009-06-09 2:37 ` Wu Fengguang
2009-06-09 2:37 ` Wu Fengguang
2009-06-09 8:19 ` KOSAKI Motohiro
2009-06-09 8:19 ` KOSAKI Motohiro
2009-06-09 8:47 ` Mel Gorman
2009-06-09 8:47 ` Mel Gorman
2009-06-08 13:01 ` [PATCH 3/3] Do not unconditionally treat zones that fail zone_reclaim() as full Mel Gorman
2009-06-08 13:01 ` Mel Gorman
2009-06-08 14:32 ` Christoph Lameter
2009-06-08 14:32 ` Christoph Lameter
2009-06-08 14:43 ` Mel Gorman
2009-06-08 14:43 ` Mel Gorman
2009-06-09 3:11 ` Wu Fengguang [this message]
2009-06-09 3:11 ` Wu Fengguang
2009-06-09 8:50 ` Mel Gorman
2009-06-09 8:50 ` Mel Gorman
2009-06-09 7:48 ` KOSAKI Motohiro
2009-06-09 7:48 ` KOSAKI Motohiro
2009-06-09 9:25 ` Mel Gorman
2009-06-09 9:25 ` Mel Gorman
2009-06-09 12:05 ` KOSAKI Motohiro
2009-06-09 12:05 ` KOSAKI Motohiro
2009-06-09 13:28 ` Mel Gorman
2009-06-09 13:28 ` 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=20090609031119.GB7875@localhost \
--to=fengguang.wu@intel.com \
--cc=cl@linux-foundation.org \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxram@us.ibm.com \
--cc=mel@csn.ul.ie \
--cc=riel@redhat.com \
--cc=yanmin.zhang@intel.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.