* Re: Linux responsiveness under heavy load [not found] <20000308223851.A9519@pcep-jamie.cern.ch> @ 2000-03-08 22:26 ` Rik van Riel 2000-03-08 22:39 ` Jamie Lokier 0 siblings, 1 reply; 2+ messages in thread From: Rik van Riel @ 2000-03-08 22:26 UTC (permalink / raw) To: Jamie Lokier; +Cc: linux-kernel, linux-mm 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/ ^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Linux responsiveness under heavy load 2000-03-08 22:26 ` Linux responsiveness under heavy load Rik van Riel @ 2000-03-08 22:39 ` Jamie Lokier 0 siblings, 0 replies; 2+ messages in thread From: Jamie Lokier @ 2000-03-08 22:39 UTC (permalink / raw) To: riel; +Cc: linux-kernel, linux-mm 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/ ^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2000-03-08 22:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20000308223851.A9519@pcep-jamie.cern.ch>
2000-03-08 22:26 ` Linux responsiveness under heavy load Rik van Riel
2000-03-08 22:39 ` Jamie Lokier
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox