Prev: vmscan: Do not writeback filesystem pages in direct reclaim
Next: vmscan: tracing: Update trace event to track if page reclaim IO is for anon or file pages
From: Christoph Hellwig on 19 Jul 2010 10:30
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?

And btw, at least currently wakeup_flusher_threads writes back nr_pages
for each BDI, which might not be what you want. Then again probably
no caller wants it, but I don't see an easy way to fix it.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rik van Riel on 19 Jul 2010 15:10
On 07/19/2010 09:11 AM, Mel Gorman wrote:
> There are a number of cases where pages get cleaned but two of concern
> to this patch are;
> o When dirtying pages, processes may be throttled to clean pages if
> dirty_ratio is not met.
> o Pages belonging to inodes dirtied longer than
> dirty_writeback_centisecs get cleaned.
>
> The problem for reclaim is that dirty pages can reach the end of the LRU
> if pages are being dirtied slowly so that neither the throttling cleans
> them or a flusher thread waking periodically.

I can't see a better way to do this without creating
a way-too-big-to-merge patch series, and this patch
should result in the right behaviour, so ...

Acked-by: Rik van Riel <riel(a)redhat.com>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 19 Jul 2010 18:30
On Mon, Jul 19, 2010 at 02:11:30PM +0100, Mel Gorman wrote:
> @@ -933,13 +934,16 @@ keep_dirty:
> VM_BUG_ON(PageLRU(page) || PageUnevictable(page));
> }
>
> + /*
> + * 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);

An argument of 0 means 'every dirty page in the system', I assume this
is not what you wanted, right? Something like this?

if (nr_dirty && !laptop_mode)
wakeup_flusher_threads(nr_dirty + nr_dirty / 2);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 19 Jul 2010 18:50
On Mon, Jul 19, 2010 at 03:37:37PM +0100, Mel Gorman wrote:
> 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);

Actually, it's not avoiding writing pages in laptop mode, instead it
is lumping writeouts aggressively (as I wrote in my other mail,
..nr_pages=0 means 'write everything') to keep disk spinups rare and
make maximum use of them.

> 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.

Maybe couple your wakeup with sc->may_writepage? It is usually false
for laptop_mode but direct reclaimers enable it at one point in
do_try_to_free_pages() when it scanned more than 150% of the reclaim
target, so you could use existing disk spin-up points instead of
introducing new ones or disabling the heuristics in laptop mode.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 20 Jul 2010 18:10
On Tue, Jul 20, 2010 at 03:10:49PM +0100, Mel Gorman wrote:
> On Tue, Jul 20, 2010 at 12:48:39AM +0200, Johannes Weiner wrote:
> > On Mon, Jul 19, 2010 at 03:37:37PM +0100, Mel Gorman wrote:
> > > 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.
> >
> > Maybe couple your wakeup with sc->may_writepage? It is usually false
> > for laptop_mode but direct reclaimers enable it at one point in
> > do_try_to_free_pages() when it scanned more than 150% of the reclaim
> > target, so you could use existing disk spin-up points instead of
> > introducing new ones or disabling the heuristics in laptop mode.
> >
>
> How about the following?
>
> if (nr_dirty && sc->may_writepage)
> wakeup_flusher_threads(laptop_mode ? 0 :
> nr_dirty + nr_dirty / 2);
>
>
> 1. Wakup flusher threads if dirty pages are encountered
> 2. For direct reclaim, only wake them up if may_writepage is set
> indicating that the system is ready to spin up disks and start
> reclaiming
> 3. In laptop_mode, flush everything to reduce future spin-ups

Sounds like the sanest approach to me. Thanks.

Hannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2 3 4
Prev: vmscan: Do not writeback filesystem pages in direct reclaim
Next: vmscan: tracing: Update trace event to track if page reclaim IO is for anon or file pages