All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Wu Fengguang <fengguang.wu@intel.com>
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 1/3] Reintroduce zone_reclaim_interval for when zone_reclaim() scans and fails to avoid CPU spinning at 100% on NUMA
Date: Wed, 10 Jun 2009 10:54:09 +0100	[thread overview]
Message-ID: <20090610095409.GC25943@csn.ul.ie> (raw)
In-Reply-To: <20090610021440.GB6597@localhost>

On Wed, Jun 10, 2009 at 10:14:40AM +0800, Wu Fengguang wrote:
> On Tue, Jun 09, 2009 at 11:06:19PM +0800, Mel Gorman wrote:
> > On Tue, Jun 09, 2009 at 09:38:04PM +0800, Wu Fengguang wrote:
> > > On Tue, Jun 09, 2009 at 05:40:50PM +0800, Mel Gorman wrote:
> > > > 
> > > > Conceivably though, zone_reclaim_interval could automatically tune
> > > > itself based on a heuristic like this if the administrator does not give
> > > > a specific value. I think that would be an interesting follow on once
> > > > we've brought back zone_reclaim_interval and get a feeling for how often
> > > > it is actually used.
> > > 
> > > Well I don't think that's good practice. There are heuristic
> > > calculations all over the kernel. Shall we exporting parameters to
> > > user space just because we are not absolutely sure? Or shall we ship
> > > the heuristics and do adjustments based on feedbacks and only export
> > > parameters when we find _known cases_ that cannot be covered by pure
> > > heuristics?
> > > 
> > 
> > Good question - I don't have a satisfactory answer but I intuitively find
> > the zone_reclaim_interval easier to deal with than the heuristic.  That said,
> > I would prefer if neither was required.
> 
> Yes - can we rely on the (improved) accounting to make our "failure feedback"
> patches unnecessary? :)
> 

Am awaiting test results to answer that question :)

> Thanks,
> Fengguang
> 
> > In the patchset, I've added a counter for the number of times that the
> > scan-avoidance heuristic fails. If the tmpfs problem has been resolved
> > (patch with bug reporter, am awaiting test), I'll drop zone_reclaim_interval
> > altogether and we'll use the counter to detect if/when this situation
> > occurs again.
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

WARNING: multiple messages have this Message-ID (diff)
From: Mel Gorman <mel@csn.ul.ie>
To: Wu Fengguang <fengguang.wu@intel.com>
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 1/3] Reintroduce zone_reclaim_interval for when zone_reclaim() scans and fails to avoid CPU spinning at 100% on NUMA
Date: Wed, 10 Jun 2009 10:54:09 +0100	[thread overview]
Message-ID: <20090610095409.GC25943@csn.ul.ie> (raw)
In-Reply-To: <20090610021440.GB6597@localhost>

On Wed, Jun 10, 2009 at 10:14:40AM +0800, Wu Fengguang wrote:
> On Tue, Jun 09, 2009 at 11:06:19PM +0800, Mel Gorman wrote:
> > On Tue, Jun 09, 2009 at 09:38:04PM +0800, Wu Fengguang wrote:
> > > On Tue, Jun 09, 2009 at 05:40:50PM +0800, Mel Gorman wrote:
> > > > 
> > > > Conceivably though, zone_reclaim_interval could automatically tune
> > > > itself based on a heuristic like this if the administrator does not give
> > > > a specific value. I think that would be an interesting follow on once
> > > > we've brought back zone_reclaim_interval and get a feeling for how often
> > > > it is actually used.
> > > 
> > > Well I don't think that's good practice. There are heuristic
> > > calculations all over the kernel. Shall we exporting parameters to
> > > user space just because we are not absolutely sure? Or shall we ship
> > > the heuristics and do adjustments based on feedbacks and only export
> > > parameters when we find _known cases_ that cannot be covered by pure
> > > heuristics?
> > > 
> > 
> > Good question - I don't have a satisfactory answer but I intuitively find
> > the zone_reclaim_interval easier to deal with than the heuristic.  That said,
> > I would prefer if neither was required.
> 
> Yes - can we rely on the (improved) accounting to make our "failure feedback"
> patches unnecessary? :)
> 

Am awaiting test results to answer that question :)

> Thanks,
> Fengguang
> 
> > In the patchset, I've added a counter for the number of times that the
> > scan-avoidance heuristic fails. If the tmpfs problem has been resolved
> > (patch with bug reporter, am awaiting test), I'll drop zone_reclaim_interval
> > altogether and we'll use the counter to detect if/when this situation
> > occurs again.
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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>

  reply	other threads:[~2009-06-10  9:54 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 [this message]
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
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=20090610095409.GC25943@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=cl@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxram@us.ibm.com \
    --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.