Messages in this thread | | | Date | Thu, 26 Jul 2007 10:19:06 -0400 | From | "Michael Chang" <> | Subject | Re: [ck] Re: -mm merge plans for 2.6.23 |
| |
On 7/26/07, Andrew Morton <akpm@linux-foundation.org> wrote: > On Wed, 25 Jul 2007 09:09:01 -0700 > "Ray Lee" <ray-lk@madrabbit.org> 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... > > 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.
Maybe I'm missing something here, but if the problem is resource allocation when switching from state A to state B, and from B to C, etc.; wouldn't it be a bad thing if state B happened to be (in the future) this state-shifting userspace daemon of which you speak? (Or is that likely to be impossible/unlikely for some other reason which alludes me at the moment?)
-- Michael Chang
Please avoid sending me Word or PowerPoint attachments. Send me ODT, RTF, or HTML instead. See http://www.gnu.org/philosophy/no-word-attachments.html Thank you. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |