Re: filemap_fdatawait() wait_on_page_writeback_range(mapping, 0,-1)?

From: Andrew Morton
Date: Thu Aug 19 2004 - 18:31:41 EST


Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
>
> On Thu, Aug 19, 2004 at 02:49:47PM -0700, Andrew Morton wrote:
> > Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx> wrote:
> > >
> > > Hi Andrew,
> > >
> > > I dont understand why we do call wait_on_page_writeback_range() with -1
> > > as the "end" argument.
> >
> > "every page in the file".
> >
> > > -1 sounds pretty stupid at first, it does unnecessary calls to
> > > the radix lookup code.
> >
> > I guess it could cause one extra call into the lookup code. There's an
> > additional check in -mm's wait_on_page_writeback_range() which would prevent
> > that.
>
> this?
>
> + /* until radix tree lookup accepts end_index */
> + if (page->index > end)
> + continue;

No, I'm being thick. Please ignore.

> What I'm trying to do is make wait_on_page_writeback_range() do reverse
> search instead ascending. Since we write pages in ascending order, doing
> the wait on reverse order makes sense and will avoid possibly tons of
> wakeups.

Yes, that's probably the low-hanging-fruit wrt CPU consumption in there.

> Naive me tried to implement that using pagevec_lookup_tag(), but I'm
> convinced we need pagevec_reverse_lookup_tag() do reverse search
> on the radix tree. I'll try getting that done on the weekend.

Yes, a descending-order gang lookup would be needed.

It'd be tricky to implement. Probably you could get just as much benefit
by simply waiting on the highest-index page prior to doing the full-range
walk. Certainly that'd be interesting as a first step: run some tests, see
what impact it has on context switch totals.

Bear in mind that while waiting on the pages in ascending-offset-order
does incur extra context switches, it also yields lowest latency. Because it
pipelines the inspection of each page with the ongoing I/O.

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