[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101026185955.GA3194@thunk.org>
Date: Tue, 26 Oct 2010 14:59:55 -0400
From: Ted Ts'o <tytso@....edu>
To: Eric Sandeen <sandeen@...hat.com>
Cc: ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH 3/3] ext4: update writeback_index based on last page
scanned
On Tue, Oct 26, 2010 at 09:57:14AM -0500, Eric Sandeen wrote:
> Ted Ts'o wrote:
> > On Mon, Oct 25, 2010 at 04:39:10PM -0500, Eric Sandeen wrote:
> >> Not compilebench specifically, but I did do some benchmarking
> >> with out of cache buffered IO; to be honest I didn't see
> >> striking performance differences, but I did see the writeback
> >> behave better in terms of not wandering all over, even if it
> >> might recover well.
> >>
> >> I can try compilebench; do you have specific concerns?
> >
> > My specific concern is that what happens if __mpage_da_writepage()
> > accumulates 200 pages, but then we were only able to accumulate 50
> > pages, and we only write 50 pages.
>
> Be patient with me, but how do we accumulate 200 pages but then only
> accumulate 50 pages?
Sorry, I typo'ed the world . What I meant was, we accumulate 200
pages of contiguously dirty, delay allocated pages in logical block
numberspace, but then we are able to only _allocate_ 50 pages worth of
blocks which are contiguous in physical block numberspace, so we only
end up writing 50 pages worth of blocks.
But with your patch we end up skipping 200 pages, even though at the
end we only wrote 50 pages.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists