Re: Two naive questions and a suggestion

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On Wed, 25 Nov 1998 07:41:41 +0100 (CET), Rik van Riel
<H.H.vanRiel@phys.uu.nl> said:

> When the mythical swapin readahead will be merged, we can
> gain some ungodly amount of speed almost for free. I don't
> know if we'll ever implement the scheduling tricks...

Agreed: usage patterns these days are very different.  We simply don't
expect to run parallel massive processes whose combined working sets
exceed physical memory these days.  Making sure that we don't thrash to
death is still an important point, but we can achieve that by
guaranteeing processes a minimum rss quota (so that only those processes
exceeding that quota compete for the remaining physical memory).

> I do have a few ideas for the scheduling stuff though, with
> RSS limits (we can safely implement those when the swap cache
> trick is implemented) and the keeping of a few statistics,
> we will be able to implement the swapping tricks.

Rick, get real: when will you work out how the VM works?  We can safely
implement RSS limits *today*, and have been able to since 2.1.89.
<grin>  It's just a matter of doing a vmscan on the current process
whenever it exceeds its own RSS limit.  The mechanism is all there.

> Without swapin readahead, we'll be unable to implement them
> properly however :(

No, we don't need readahead (although the swap cache itself already
includes all of the necessary mechanism: rw_swap_page(READ, nowait) will
do it).  The only extra functionality we might want is extra control
over when we write swap-cached pages: right now, all dirty pages need to
be in the RSS, and we write them to disk when we evict them to the swap
cache.  Thus, only clean pages can be in the swap cache.  If we want to
support processes with a dirty working set > RSS, we'd need to extend
this.

--Stephen
--
This is a majordomo managed list.  To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org