From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mel@csn.ul.ie>, 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 15:04:21 +0900 (JST) [thread overview]
Message-ID: <20110118142339.6705.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1101172108380.29048@chino.kir.corp.google.com>
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;
}
Now, we have three preferred_zone usage.
1. for zone stat
2. wait_iff_congested
3. for calculate compaction duration
So, I have two question.
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.
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?
3. I'm not sure why zone->compact_defer is not noted per zone, instead
noted only preferred zone. Do you know the intention?
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?
> wait_iff_congested(), though, uses preferred_zone to determine if the
> congestion wait should be deferred because its dirty pages are backed by
> a congested bdi. This incorrectly defers the timeout and busy loops in
> the page allocator with various cond_resched() calls if preferred_zone is
> not allowed in the current context, usually consuming 100% of a cpu.
>
> This patch resets preferred_zone to an allowed zone in the slowpath if
> the allocation context is constrained by current's cpuset. It also
> ensures preferred_zone is from the set of allowed nodes when called from
> within direct reclaim; allocations are always constrainted by cpusets
> since the context is always blockable.
>
> Both of these uses of cpuset_current_mems_allowed are protected by
> get_mems_allowed().
--
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>
next prev parent reply other threads:[~2011-01-18 6:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-18 5:09 David Rientjes
2011-01-18 6:04 ` KOSAKI Motohiro [this message]
2011-01-18 10:29 ` Mel Gorman
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=20110118142339.6705.A69D9226@jp.fujitsu.com \
--to=kosaki.motohiro@jp.fujitsu.com \
--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=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--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