Messages in this thread | | | Date | Thu, 19 Aug 2004 16:33:36 -0700 | From | Andrew Morton <> | Subject | Re: filemap_fdatawait() wait_on_page_writeback_range(mapping, 0, -1)? |
| |
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |