On Mon, Jul 19, 2010 at 10:23:49AM -0400, Christoph Hellwig wrote: > On Mon, Jul 19, 2010 at 02:11:30PM +0100, Mel Gorman wrote: > > + /* > > + * If reclaim is encountering dirty pages, it may be because > > + * dirty pages are reaching the end of the LRU even though > > + * the dirty_ratio may be satisified. In this case, wake > > + * flusher threads to pro-actively clean some pages > > + */ > > + wakeup_flusher_threads(laptop_mode ? 0 : nr_dirty + nr_dirty / 2); > > + > > Where is the laptop-mode magic coming from? > It comes from other parts of page reclaim where writing pages is avoided by page reclaim where possible. Things like this wakeup_flusher_threads(laptop_mode ? 0 : total_scanned); and .may_writepage = !laptop_mode although the latter can get disabled too. Deleting the magic is an option which would trade IO efficiency for power efficiency but my current thinking is laptop mode preferred reduced power. > And btw, at least currently wakeup_flusher_threads writes back nr_pages > for each BDI, which might not be what you want. I saw you pointing that out in another thread all right although I can't remember the context. It's not exactly what I want but then again we really want writing back of pages from a particular zone which we don't get either. There did not seem to be an ideal here and this appeared to be "less bad" than the alternatives. > Then again probably > no caller wants it, but I don't see an easy way to fix it. > I didn't either but my writeback-foo is weak (getting better but still weak). I hoped to bring it up at MM Summit and maybe at the Filesystem Summit too to see what ideas exist to improve this. When this idea was first floated, you called it a band-aid and I prioritised writing back old inodes over this. How do you feel about this approach now? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
