Messages in this thread |  | | Date | Tue, 3 Jul 2001 12:33:50 +0200 (CEST) | From | Marco Colombo <> | Subject | Re: VM Requirement Document - v0.0 |
| |
On Mon, 2 Jul 2001, Rik van Riel wrote:
> On Thu, 28 Jun 2001, Marco Colombo wrote: > > > I'm not sure that, in general, recent pages with only one access are > > still better eviction candidates compared to 8 hours old pages. Here > > we need either another way to detect one-shot activity (like the one > > performed by updatedb), > > Fully agreed, but there is one problem with this idea. > Suppose you have a maximum of 20% of your RAM for these > "one-shot" things, now how are you going to be able to > page in an application with a working set of, say, 25% > the size of RAM ? > > If you don't have any special measures, the pages from > this "new" application will always be treated as one-shot > pages and the process will never be able to be cached in > memory completely...
I see your point. Running Gnome on a 64MB box means you have most of the pages that are "warm" (using my definition), so there's little room for "cold" (new) pages, and maybe they don't get a chance of being accessed a second time before they are evicted, which leads to thrashing if you're trying to start something really big (well, I guess the access pattern within a typical ws is not uniformly distributed, so some pages will get accessed twice, but I see the problem).
I'll try and make my point a bit clearer. I was referring to background aging only. When aging is caused by pressure, you don't make any difference between pages. I don't know how the idea to give high values for page->age on the second access instead of the first is going to be implemented, but I'm assuming that new pages are going to be placed on the active list with a low age value (PAGE_AGE_START_FIRST ?), maybe even 0 (well, I'm not a guru of course). I'm just saying that, to avoid Mike's "problem" (which BTW I don't believe is a big one, really), we could stop background aging on interactive pages (short form for "pages that belong to the ws of an interactive process") at a certain miminum age, say PAGE_AGE_BG_INTERACTIVE_MINIMUM, with PAGE_AGE_BG_INTERACTIVE_MINIMUM > PAGE_AGE_START_FIRST). Weighting the difference between the two ages, you can give long-standing interactive pages some advantage vs new pages. But they will be aged below PAGE_AGE_START_FIRST and eventually moved to the inactive list. After all, they *are* good candidates. Does this make some sense?
Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only when background aging, maybe it's not enough to keep processes like updatedb from causing interactive pages to be evicted. That's why I said we should have another way to detect that kind of activity... well, the application could just let us know (no need to embed an autotuning-genetic-page-replacement-optimizer into the kernel). We should just drop all FS metadata accessed by updatedb, since we know that's one-shot only, without raising pressure at all. Just like (not that I'm proposing it) putting those "one-shot" pages directly on the inactive-clean list instead of the active list. How an application could declare such a behaviour is an open question, of course. Maybe it's even possible to detect it. And BTW that's really fine tuning. Evicting an 8 hours old page may be a mistake sometime, but it's never a *big* mistake.
> > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ http://distro.conectiva.com/ > > Send all your spam to aardvark@nl.linux.org (spam digging piggy)
.TM. -- ____/ ____/ / / / / Marco Colombo ___/ ___ / / Technical Manager / / / ESI s.r.l. _____/ _____/ _/ Colombo@ESI.it
- 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/
|  |