Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: VM Requirement Document - v0.0 | Date | Tue, 3 Jul 2001 17:04:58 +0200 |
| |
On Tuesday 03 July 2001 12:33, Marco Colombo wrote: > 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.
Note that some of updatedb's metadata pages are of the accessed-often kind, e.g., directory blocks and inodes. A blanket low priority on all the pages updatedb touches just won't do.
> 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.
IMHO, updatedb *should* evict all the "interactive" pages that aren't actually doing anything[1]. That way it should run faster, provided of course its accessed-once pages are properly given low priority.
I see three page priority levels:
0 - accessed-never/aged to zero 1 - accessed-once/just loaded 2 - accessed-often
with these transitions:
0 -> 1, if a page is accessed 1 -> 2, if a page is accessed a second time 1 -> 0, if a page gets old 2 -> 0, if a page gets old
The 0 and 1 level pages are on a fifo queue, the 2 level pages are scanned clock-wise, relying on the age computation[2]. Eviction candidates are taken from the cold end of the 0 level list, unless it is empty, in which case they are taken from the 1 level list. In desperation, eviction candidates are taken from the 2 level list, i.e., random eviction policy, as opposed to what we do now which is to initiate an emergency scan of the active list for new inactive candidates - rather like calling a quick board meeting when the building is on fire.
Note that the above is only a very slight departure from the current design. And by the way, this is just brainstorming, it hasn't reached the 'proposal' stage yet.
[1] It would be nice to have a mechanism whereby the evicted 'interactive' pages are automatically reloaded when updatedb has finished its work. This is a case of scavenging unused disk bandwidth for something useful, i.e., improving the interactive experience.
[2] I much prefer the hot/cold terminology over old/young. The latter gets confusing because a 'high' age is 'young'. I'd rather think of a high value as being 'hot'.
-- Daniel - 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/
| |