Re: Linux responsiveness under heavy load

Re: Linux responsiveness under heavy load

[Rik van Riel]

On Wed, 8 Mar 2000, Jamie Lokier wrote:

	[snip awful performance under load]
> A larger boost to keep-the-page-in-memory priority for pages
> referenced by "interactive" processes might be in order.  
> Either faster vmscanning simply a higher priority for pages
> found to be used.  Might not be too hard to implement either.

Indeed it shouldn't be. Having a two-phase NRU unmapping in the
page table scanning and a maybe better LRU reclamation in
shrink_mmap() may help here, but the CPU cost may put some
people off...

Then again, not having this better memory reclamation is probably
more expensive than having it :)

Now where did I put that asbestos underwear?

> A larger priority for page-in I/O due to interactive process too
> might help too.  Some modification of Andrea's elevator.  But
> that doesn't seem so easy.

Read requests are easily tied to a process, so this could
be relatively easy. Doing it properly before 2.5 may be a
little difficult though ...

regards,

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.

http://www.conectiva.com/		http://www.surriel.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Linux responsiveness under heavy load

[Jamie Lokier]

Rik van Riel wrote:
> > A larger priority for page-in I/O due to interactive process too
> > might help too.  Some modification of Andrea's elevator.  But
> > that doesn't seem so easy.
> 
> Read requests are easily tied to a process, so this could
> be relatively easy. Doing it properly before 2.5 may be a
> little difficult though ...

A simple flag with each I/O request meaning "high priority due to
interactive process I/O".  Make the elevator select high priority
requests before low ones, with the same sequence number bound for
fairness as has recently been implemented.

Maybe even a small holdoff time when going from handling a high priority
to a low priority request, to give the interactive process a few
microseconds to stimulate another page in.  (Actually a small holdoff in
general between I/O "here" and I/O "far away" might improve overall seek
times, orthogonal to priority issues).

It does seem too simple to work, but has anyone tried it?

-- Jamie
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/