[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49219B61.2080800@redhat.com>
Date: Mon, 17 Nov 2008 11:27:13 -0500
From: Rik van Riel <riel@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Andrew Morton <akpm@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
Gene Heskett <gene.heskett@...il.com>
Subject: Re: [PATCH] mm: evict streaming IO cache first
Linus Torvalds wrote:
>
> On Mon, 17 Nov 2008, KAMEZAWA Hiroyuki wrote:
>> How about resetting zone->recent_scanned/rotated to be some value calculated from
>> INACTIVE_ANON/INACTIVE_FILE at some time (when the system is enough idle) ?
>
> .. or how about just considering the act of adding a new page to the LRU
> to be a "scan" event? IOW, "scanning" is not necessarily just an act of
> the VM looking for pages to free, but would be a more general "activity"
> meter.
That might work.
Adding a new page to the inactive file list would increment
zone->recent_scanned[file].
Adding a new anonymous page to the active anon list could
increment both zone->recent_scanned[anon] and
zone->recent_rotated[anon].
That way adding anonymous memory would move some pressure
to the file side, while doing lots of streaming IO would
result in the same.
> That would seem to be the right kind of thing to do: if we literally have
> a load that only does streaming and pages never get moved to the active
> LRU, it should basically keep the page cache close to constant size -
> which is just another way of saying that we should only be scanning page
> cache pages.
The only thing left at that point is the fact that the
streaming IO puts pressure on the working set in the
page cache, by always decreasing the active file list
too. But that's a different thing entirely and can be
looked at later :)
Your idea looks like it should work. I'll whip up a patch
for Gene Heskett.
--
All rights reversed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists