Re: merging the per-bdi writeback patchset

From: KOSAKI Motohiro
Date: Tue Jun 23 2009 - 07:44:36 EST

> > > > Can you please make reproduce program and post mesurement result?
> > > > I hope to mesure the same program on my box.
> > >
> > > For which issue? Lumpy writeout can often be observed just by doing
> > > buffered writes to a bunch of files.
> >
> > Yes, I know current behavior is not perfectly optimal.
> > but I haven't seen it cause serious issue.
> >
> > Then, I guess you have big degression workload, yes? if so, I hope to
> > see it.
> Not really, I was just interested in making it more optimal. I work from
> various fio job files, one case that is sped up greatly is doing random
> writes with mmap to an otherwise buffered file. pdflush is both lumpy
> and a lot slower there, even with many pdflush threads active. Looking
> at disk utilization, pdflush doesn't manage more than ~80% for that. The
> per-bdi writeback is completely smooth and gets about as close to 100%
> utilization as possible (around ~98% there). And this is just one 1
> disk, the per-bdi writeback scales nicely upwards. pdflush falls flat.
> And then there are lots of cases where the performance is the same. For
> many workloads, pdflush isn't really very active.
> > > > Plus, Can you please write more vervose patch description? your patch is a
> > > > bit harder review.
> > >
> > > OK, I can probably improve on that. Do you mean the general description
> > > of the patchset, or some of the individual patches?
> >
> > Hopefully both. honestly I haven't understand your main worryed issue.
> Does the above help? It's all about making the writeback more
> consistent. So getting rid of the lumpy writeback and eliminating the
> pdflush starvation were the prime motivators.

ok, thanks.
I try to review your patch series without any bias later.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at