Re: Two naive questions and a suggestion

[Rik van Riel <H.H.vanRiel@phys.uu.nl>]

On Wed, 25 Nov 1998, Stephen C. Tweedie wrote:
> <H.H.vanRiel@phys.uu.nl> said:
> 
> It is not there in 2.1.130-pre3, however. :) That misses the point,
> though.  The point is that it is trivial to remove these mappings
> without freeing the swap cache, and the code you point to confirms this:

OK, point taken. {:-)

> > Oh, one question. Can we attach a swap page to the swap cache
> > while there's no program using it? This way we can implement
> > a very primitive swapin readahead right now, improving the
> > algorithm as we go along...
> 
> Yes, rw_swap_page(READ, nowait) does exactly that: it primes the
> swap cache asynchronously but does not map it anywhere.  It should
> be completely safe right now: the normal swap read is just a special
> case of this. 

Then I think it's time to do swapin readahead on the
entire SWAP_CLUSTER (or just from the point where we
faulted) on a dumb-and-dumber basis, awaiting a good
readahead scheme. Of course it will need to be sysctl
tuneable :)

The reason I propose this dumb scheme is because we
can read one SWAP_CLUSTER_MAX sized chunk in one
sweep without having to move the disks head... Plus
Linus might actually accept a change like this :)

> > If we keep a quota of 20% of memory in buffers and unmapped
> > cache, we can also do away with a buffer for the 8 and 16kB
> > area's. We can always find some contiguous area in swap/page
> > cache that we can free...
> 
> That will kill performance if you have a large simulation which has a
> legitimate need to keep 90% of physical memory full of anonymous pages.
> I'd rather do without that 20% magic limit if we can.  The only special
> limit we really need is to make sure that kswapd keeps far enough in
> advance of interrupt memory load that the free list doesn't empty.

OK, then we should let the kernel calculate the limit itself
based on the number of soft faults, swapout pressure, memory
pressure and process priority.

We can also use stats like this to temporarily suspend very
large processes when we've got multiple processes with:
 (p->vm_mm->rss + p->dec_flt) > RSS_THRASH_LIMIT, where
p->dec_flt is a floating average and the RSS limit is
calculated dynamically as well... I know this could be
a slightly expensive trick, but we can easily make that
sysctl tuneable as well.

Rik -- slowly getting used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide.        H.H.vanRiel@phys.uu.nl |
| Scouting Vries cubscout leader.      http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+


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