On Wed, 25 Jul 2007 09:09:01 -0700 "Ray Lee" <[EMAIL PROTECTED]> wrote:
> No, there's a third case which I find the most annoying. I have > multiple working sets, the sum of which won't fit into RAM. When I > finish one, the kernel had time to preemptively swap back in the > other, and yet it didn't. So, I sit around, twiddling my thumbs, > waiting for my music player to come back to life, or thunderbird, > or... Yes, I'm thinking that's a good problem statement and it isn't something which the kernel even vaguely attempts to address, apart from normal demand paging. We could perhaps improve things with larger and smarter fault readaround, perhaps guided by refault-rate measurement. But that's still demand-paged rather than being proactive/predictive/whatever. None of this is swap-specific though: exactly the same problem would need to be solved for mmapped files and even plain old pagecache. In fact I'd restate the problem as "system is in steady state A, then there is a workload shift causing transition to state B, then the system goes idle. We now wish to reinstate state A in anticipation of a resumption of the original workload". swap-prefetch solves a part of that. A complete solution for anon and file-backed memory could be implemented (ta-da) in userspace using the kernel inspection tools in -mm's maps2-* patches. We would need to add a means by which userspace can repopulate swapcache, but that doesn't sound too hard (especially when you haven't thought about it). And userspace can right now work out which pages from which files are in pagecache so this application can handle pagecache, swap and file-backed memory. (file-backed memory might not even need special treatment, given that it's pagecache anyway). And userspace can do a much better implementation of this how-to-handle-large-load-shifts problem, because it is really quite complex. The system needs to be monitored to determine what is the "usual" state (ie: the thing we wish to reestablish when the transient workload subsides). The system then needs to be monitored to determine when the exceptional workload has started, and when it has subsided, and userspace then needs to decide when to start reestablishing the old working set, at what rate, when to abort doing that, etc. All this would end up needing runtime configurability and tweakability and customisability. All standard fare for userspace stuff - much easier than patching the kernel. So. We can a) provide a way for userspace to reload pagecache and b) merge maps2 (once it's finished) (pokes mpm) and we're done? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
