| |||||||||||||
Can swap-in be improved?Can swap-in be improved?Posted May 26, 2007 2:10 UTC (Sat) by giraffedata (subscriber, #1954)In reply to: Can swap-in be improved? by MathFox Parent article: On-demand readahead
One thing that would improve this and various other things is actual swapping. What we call swapping in Linux is really just virtual memory paging. Swapping is a much older technology in which you remove an entire process from memory to let other processes run, then bring the entire process back when it's turn comes around again. It's also known as long term scheduling. If Linux could notice that a process hasn't accessed any of its pages (hasn't run) in a long time, it could write all the resident pages out to contiguous swap space. The next time the process runs, it could read it all back. Furthermore, if Linux is stealing a page that was accessed quite recently, it ought to steal them all and then wait a while before swapping them all back in again and swapping out somebody else. By the way, it would be a mistake to believe that all that paging activity when you sit down to a long-idle session is Linux "swapping." A lot of it is reading in memory mapped program files. Speeding that up isn't as easy.
(Log in to post comments)
Can swap-in be improved? Posted May 31, 2007 17:04 UTC (Thu) by anton (guest, #25547) [Link] A lot of it is reading in memory mapped program files. Speeding that up isn't as easy.I think it's not very hard. You just need some history-based prediction mechanism. A student of mine has done his Master's thesis (in German) on speeding up the startup time of programs by recording the blocks accessed when starting a program, and then prefetching them (Windows XP does something like that for the OS startup). Similarly, one could record the pages or blocks accessed soon after a major page fault, and then prefetch all of them the next time the page faults.
Can swap-in be improved? Posted Jun 2, 2007 2:30 UTC (Sat) by giraffedata (subscriber, #1954) [Link] That's actually different, and a little harder, than what we're talking about here. We're talking about resuming a process that has been idle for a while. So all the history you need is the list of pages that were resident the last time the process ran.That by itself can't get you to the level of speed that we discussed with anonymous pages, where all those pages were contiguous on disk. I know I've seen somewhere a system where you don't ordinarily start a program, but rather reload and resume an entire process. In that case, the two prefetching problems are probably the same.
Can swap-in be improved? Posted Jun 7, 2007 13:29 UTC (Thu) by anton (guest, #25547) [Link] Yes, fetching all the pages that were resident is certainly an approach for the problem that would work.Using a history-based prefetcher might have the following advantages, though:
Can swap-in be improved? Posted Jul 25, 2007 23:00 UTC (Wed) by Blaisorblade (guest, #25465) [Link] > A lot of it is reading in memory mapped program files. Speeding that up> isn't as easy.
Surely swap prefetch won't help here, indeed. But good readahead would.
About swapping, the reason it's old is that, as Rik van Riel (and another
> Furthermore, if Linux is stealing a page that was accessed quite
Well, the swap token was introduced by Rik van Riel to implement something
|
|||||||||||||