Re: [PATCH] kswapd should only wait on IO if there is IO

From: Andrew Morton
Date: Thu Sep 27 2007 - 19:00:27 EST


On Thu, 27 Sep 2007 18:50:27 -0400
Rik van Riel <riel@xxxxxxxxxx> wrote:

> On Thu, 27 Sep 2007 15:21:21 -0700
> Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > > Nope, sc.nr_io_pages will also be incremented when the code runs into
> > > pages that are already PageWriteback.
> >
> > yup, I didn't think of that. Hopefully someone else will be in there
> > working on that zone too. If this caller yields and defers to kswapd
> > then that's very likely. Except we just took away the ability to do that..
>
> if (PageDirty(page)) {
> if (sc->order <= PAGE_ALLOC_COSTLY_ORDER && referenced)
> goto keep_locked;
> if (!may_enter_fs)
> goto keep_locked;
>
> I think we can fix that problem by adding a sc->nr_io_pages++
> between the last if and the goto keep_locked in shrink_page_list.
>
> That way !GFP_IO or !GFP_FS tasks will cause themselves to sleep
> if there are pages that need to be written out, even if those
> pages are not in flight to disk yet.

yeah, that's prudent I guess.

> I have also added the comment you wanted.

And lost the changelog ;)

> - if (sc.nr_scanned && priority < DEF_PRIORITY - 2)
> + if (sc.nr_scanned && priority < DEF_PRIORITY - 2 &&
> + sc.nr_io_pages > sc.swap_cluster_max)

I do think this design decision needs a bit of explanation too.

> congestion_wait(WRITE, HZ/10);
> }
> /* top priority shrink_caches still had more to do? don't OOM, then */
> @@ -1315,6 +1330,7 @@ loop_again:
> if (!priority)
> disable_swap_token();
>
> + sc.nr_io_pages = 0;
> all_zones_ok = 1;
>
> /*
> @@ -1398,7 +1414,8 @@ loop_again:
> * OK, kswapd is getting into trouble. Take a nap, then take
> * another pass across the zones.
> */
> - if (total_scanned && priority < DEF_PRIORITY - 2)
> + if (total_scanned && priority < DEF_PRIORITY - 2 &&

As did that one. Ho hum :( Maybe it's in the git history somewhere.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/