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

[Andrew Morton <akpm@osdl.org>]

Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> On Thu, Aug 19, 2004 at 02:49:47PM -0700, Andrew Morton wrote:
> > Marcelo Tosatti <marcelo.tosatti@cyclades.com> 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.