On 07/29/2007 01:41 PM, david@xxxxxxx wrote:
I agree that tinkering with the core VM code should not be done lightly,
but this has been put through the proper process and is stalled with no
hints on how to move forward.
It has not. Concerns that were raised (by specifically Nick Piggin) weren't being addressed.
forget the nightly cron jobs for the moment. think of this scenerio. you
have your memory fairly full with apps that you have open (including
firefox with many tabs), you receive a spreadsheet you need to look at, so
you fire up openoffice to look at it. then you exit openoffice and try
to go back to firefox (after a pause while you walk to the printer to
get the printout of the spreadsheet)
And swinging a dead rat from its tail facing east-wards while reciting Documentation/CodingStyle.
Okay, very very sorry, that was particularly childish, but that "walking to the printer" is ofcourse completely constructed and this _is_ something to take into account.
Swap-prefetch wants to be free, which (also again) it is doing a good job at it seems, but this also means that it waits for the VM to be _very_ idle before it does anything and as such, we cannot just forget the "nightly" scenario and pretend it's about something else entirely. As long as the machine's being used, swap-prefetch doesn't kick in.
> -- 3: no serious consideration of possible alternatives
> > Tweaking existing use-oce logic is one I've heard but if we consider > the i/dcache issue dead, I believe that one is as well. Going to > userspace is another one. Largest theoretical potential. I myself am > extremely sceptical about the Linux userland, and largely equate it > with "smallest _practical_ potential" -- but that might just be me.
> > A larger swap granularity, possible even a self-training > granularity. Up to now, seeks only get costlier and costlier with > respect to reads with every generation of disk (flash would largely > overcome it though) and doing more in one read/write _greatly_ > improves throughput, maybe up to the point that swap-prefetch is no > longer very useful. I myself don't know about the tradeoffs > involved.
larger swap granularity may help, but waiting for the user to need the
ram and have to wait for it to be read back in is always going to be
worse for the user then pre-populating the free memory (for the case
where the pre-population is right, for other cases it's the same). so
I see this as a red herring
I saw Chris Snook make a good post here and am going to defer this part to that discussion:
http://lkml.org/lkml/2007/7/27/421
But no, it's not a red herring if _practically_ speaking the swapin is fast enough once started that people don't actually mind anymore since in that case you could simply do without yet more additional VM complexity (and kernel daemon).
there are fully legitimate situations where this is useful, the 'papering
over' effect is not referring to these, it's referring to other possible
problems in the future.
No, it's not just future. Just look at the various things under discussion now such as improved use-once and better swapin.