Re: [PATCH 00/17] [RFC] soft and dynamic dirty throttling limits

From: Dave Chinner
Date: Sat Nov 06 2010 - 06:45:53 EST


On Fri, Nov 05, 2010 at 10:56:39PM +0800, Wu Fengguang wrote:
> On Thu, Nov 04, 2010 at 09:12:28PM +0800, Christoph Hellwig wrote:
> > On Thu, Nov 04, 2010 at 11:41:19AM +0800, Wu Fengguang wrote:
> > > I'm feeling relatively good about the first 14 patches to do IO-less
> > > balance_dirty_pages() and larger writeback chunk size. I'll repost
> > > them separately as v2 after returning to Shanghai.
> >
> > Going for as small as possible patchsets is a pretty good idea. Just
> > getting the I/O less balance_dirty_pages on it's own would be a really
> > good start, as that's one of the really criticial pieces of
> > infrastructure that a lot of people are waiting for. Getting it into
> > linux-mm/linux-next ASAP so that it gets a lot of testing would be
> > highly useful.
>
> OK, I'll do a smaller IO-less balance_dirty_pages() patchset (it's
> good to know which part is the most relevant one, which is not always
> obvious by my limited field experiences), which will further reduce
> the possible risk of unexpected regressions.

Which is good given the recent history of writeback mods. :/

> Currently the -mm tree includes Greg's patchset "memcg: per cgroup
> dirty page accounting". I'm going to rebase my patches onto it,
> however I'd like to first make sure if Greg's patches are going to be
> pushed in the next merge window. I personally have no problem with
> that. Andrew?

Well, I'd prefer that you provide a git tree that I can just pull
into my current working branch to test. Having to pull in a thousand
other changes to test your writeback changes makes it much harder
for me as I'd have to establish a new stable performance/behavioural
baseline before starting to analyse your series. If it's based on
mainline then I've already got that baseline....

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx
--
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/