linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Minchan Kim <minchan.kim@gmail.com>,
	Wu Fengguang <fengguang.wu@intel.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Rik van Riel <riel@redhat.com>, Jens Axboe <axboe@kernel.dk>,
	linux-mm@kvack.org
Subject: Re: [patch] mm: fix deferred congestion timeout if preferred zone is not allowed
Date: Tue, 18 Jan 2011 10:29:41 +0000	[thread overview]
Message-ID: <20110118102941.GG27152@csn.ul.ie> (raw)
In-Reply-To: <20110118142339.6705.A69D9226@jp.fujitsu.com>

On Tue, Jan 18, 2011 at 03:04:21PM +0900, KOSAKI Motohiro wrote:
> Hi,
> 
> > Before 0e093d99763e (writeback: do not sleep on the congestion queue if
> > there are no congested BDIs or if significant congestion is not being
> > encountered in the current zone), preferred_zone was only used for
> > statistics and to determine the zoneidx from which to allocate from given
> > the type requested.
> 
> True. So, following comment is now bogus. ;)
> 
> __alloc_pages_nodemask()
> {
> (snip)
>         get_mems_allowed();
>         /* The preferred zone is used for statistics later */
>         first_zones_zonelist(zonelist, high_zoneidx, nodemask, &preferred_zone);
>         if (!preferred_zone) {
>                 put_mems_allowed();
>                 return NULL;
>         }
> 

At best, it's misleading. It is used for staistics later but it's not
all it's used for.

> 
> Now, we have three preferred_zone usage.
>  1. for zone stat
>  2. wait_iff_congested
>  3. for calculate compaction duration
> 

For 3, it is used to determine if compaction should be deferred. I'm not
sure what it has to do with the duration of compaction.

> So, I have two question.  
> 

three questions :)

> 1. Why do we need different vm stat policy mempolicy and cpuset? 
> That said, if we are using mempolicy, the above nodemask variable is 
> not NULL, then preferrd_zone doesn't point nearest zone. But it point 
> always nearest zone when cpuset are used. 
> 

I think this is historical. cpuset and mempolicy were introduced at
different times and never merged together as they should have been. I
think an attempt was made a very long time ago but there was significant
resistance from SGI developers who didn't want to see regressions
introduced in a feature they depended heavily on.

> 2. Why wait_iff_congested in page_alloc only wait preferred zone? 
> That said, theorically, any no congested zones in allocatable zones can
> avoid waiting. Just code simplify?
> 

The ideal for page allocation is that the preferred zone is always used.
If it is congested, it's probable that significant pressure also exists on
the other zones in the zonelist (because an allocation attempt failed)
but if the preferred zone is uncongested, we should try reclaiming from
it rather than going to sleep.

> 3. I'm not sure why zone->compact_defer is not noted per zone, instead
> noted only preferred zone. Do you know the intention?
> 

If we are deferring compaction, we have failed to compact the preferred
zone and all other zones in the zonelist. Updating the preferred zone is
sufficient for future allocations of the same type. We could update all
zones in the zonelist but it's unnecessary overhead and gains very little.

> I mean my first feeling tell me that we have a chance to make code simplify
> more.
> 
> Mel, Can you please tell us your opinion?
> 

Right now, I'm thinking that cpuset_current_mems_allowed should be used
as a nodemask earlier so that preferred_zone gets initialised as a
sensible value early on.

-- 
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-01-18 10:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-18  5:09 [patch] mm: fix deferred congestion timeout if preferred zone is not allowed David Rientjes
2011-01-18  6:04 ` KOSAKI Motohiro
2011-01-18 10:29   ` Mel Gorman [this message]
2011-01-19 12:48     ` KOSAKI Motohiro
2011-01-18 10:15 ` Mel Gorman
2011-01-18 20:24   ` David Rientjes
2011-01-18 20:42     ` Mel Gorman
2011-01-19  1:51       ` David Rientjes
2011-01-19 13:01     ` KOSAKI Motohiro
2011-01-19 18:37       ` David Rientjes
2011-01-19 12:52   ` KOSAKI Motohiro
2011-01-19  0:43 ` Minchan Kim
2011-01-19  1:53   ` David Rientjes
2011-01-19  4:10     ` Minchan Kim
2011-01-19 19:59     ` Christoph Lameter
2011-01-19 20:06       ` Andi Kleen
2011-01-19 20:18         ` David Rientjes
2011-01-19 23:07           ` Christoph Lameter
2011-01-20  0:59           ` Minchan Kim
2011-01-23 22:30 ` [patch v2] " David Rientjes
2011-01-24 17:16   ` 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=20110118102941.GG27152@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=fengguang.wu@intel.com \
    --cc=hannes@cmpxchg.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-mm@kvack.org \
    --cc=minchan.kim@gmail.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.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).