Message-ID: <49283A05.1060009@redhat.com>
Date: Sat, 22 Nov 2008 11:57:41 -0500
From: Rik van Riel <riel@redhat.com>
Organization: Red Hat, Inc
User-Agent: Thunderbird 2.0.0.17 (X11/20080915)
MIME-Version: 1.0
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
CC: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org,
       linux-mm@kvack.org
Subject: Re: [PATCH -mm] vmscan: bail out of page reclaim after swap_cluster_max
 pages
References: <20081116163915.F208.KOSAKI.MOTOHIRO@jp.fujitsu.com> <20081115235410.2d2c76de.akpm@linux-foundation.org> <20081122191258.26B0.KOSAKI.MOTOHIRO@jp.fujitsu.com>
In-Reply-To: <20081122191258.26B0.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1195
Lines: 31

KOSAKI Motohiro wrote:

> Rik, sorry, I nak current your patch. 
> because it don't fix old akpm issue.

You are right.  We do need to keep pressure between zones
equivalent to the size of the zones (or more precisely, to
the number of pages the zones have on their LRU lists).

However, having dozens of direct reclaim tasks all getting
to the lower priority levels can be disastrous, causing
extraordinarily large amounts of memory to be swapped out
and minutes-long stalls to applications.

I think we can come up with a middle ground here:
- always let kswapd continue its rounds
- have direct reclaim tasks continue when priority == DEF_PRIORITY
- break out of the loop for direct reclaim tasks, when
   priority < DEF_PRIORITY and enough pages have been freed

Does that sound like it would mostly preserve memory pressure
between zones, while avoiding the worst of the worst when it
comes to excessive page eviction?

-- 
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/