Messages in this thread | | | Date | Tue, 10 Jul 2007 22:47:04 -0700 | From | "Ray Lee" <> | Subject | Re: [ck] Re: -mm merge plans for 2.6.23 |
| |
On 7/10/07, Nick Piggin <nickpiggin@yahoo.com.au> wrote: > Matthew Hawkins wrote: > > On 7/11/07, Andrew Morton <akpm@linux-foundation.org> wrote: > > > Anyhow with swap prefetch, applications that may have been sitting > > there idle for a while become responsive in the single-digit seconds > > rather than double-digit or worse. The same goes for a morning wakeup > > (ie after nightly cron jobs throw things out) > > OK that's a good data point. It would be really good to be able to > do an analysis on your overnight IO patterns and the corresponding > memory reclaim behaviour and see why things are getting evicted.
Eviction can happen for multiple reasons, as I'm sure you're painfully aware. It can happen because of poor balancing choices, or it can happen because the system is just short of RAM for the workload. As for the former, you're absolutely right, it would be good to know where those come from and see if they can be addressed.
However, it's the latter that swap prefetch can help and no amount of fiddling with the aging code can address.
As an honest question, what's it going to take here? If I were to write something that watched the task stats at process exit (cool feature, that), and recorded the IO wait time or some such, and showed it was lower with a kernel with the prefetch, would *that* get us some forward motion on this?
I mean, from my point of view, it's a simple mental proof to show that if you're out of RAM for your working set, things that you'll eventually need again will get kicked out, and prefetch will bring those back in before normal access patterns would fault them back in under today's behavior. That seems like an obvious win. Where's the corresponding obvious loss that makes this a questionable addition to the kernel?
Ray - 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/
| |