Messages in this thread | | | Date | Tue, 10 Jul 2007 23:04:59 -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: > >> 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 > > s/balancing/reclaim, yes. And for the nightly cron job case, this is > could quite possibly be the cause. At least updatedb should be fairly > easy to apply use-once heuristics for, so if they're not working then > we should hopefully be able to improve it.
<nod> Sorry, I'm not so clear on the terminology, am I.
So, that's one part of it: one could argue that for that bit swap prefetch is a bit of a band-aid over the issue. A useful band-aid, that works today, isn't invasive, and can be ripped out at some future time if the underlying issue is eventually solved by a proper use-once aging mechanism, but nevertheless a band-aid.
The other part is when I've got evolution and a few other things open, then I run gimp on a raw photo and do some work on it, quit out of gimp, do a couple of things in a shell to upload the photo to my server, then switch back to evolution. Hang, waiting on swap in. Well, the kernel had some free time there to repopulate evolution's working set, and swap prefetch would help that, while better (or perfect!) heuristics in the reclaim *won't*.
That's the real issue here. - 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/
| |