On Wed, May 09, 2012 at 01:37:20PM +0200, Jan Kara wrote:
> Hello,
>
> On Mon 07-05-12 22:43:44, Wu Fengguang wrote:
> > On Fri, May 04, 2012 at 12:39:18AM +0200, Jan Kara wrote:
> > > this is the second iteration of my patches for flexible proportions. Since
> > > previous submission, I've converted BDI proportion calculations to use flexible
> > > proportions so now we can test proportions in kernel. Fengguang, can you give
> > > them a run in your JBOD setup? You might try to tweak VM_COMPLETIONS_PERIOD_LEN
> > > if things are fluctuating too much... I'm not yet completely decided how to set
> > > that constant. Thanks!
> >
> > Kara, I've got some results and it's working great. Overall performance
> > remains good. The default VM_COMPLETIONS_PERIOD_LEN = 0.5s is obviously
> > too small, so I tried increasing it to 3s and then 8s. Results for xfs
> > (which has most fluctuating IO completions and ditto for bdi_setpoint)
> > are attached. The XFS result of vanilla 3.3 is also attached. The
> > graphs are all for case bay/JBOD-2HDD-thresh=1000M/xfs-10dd.
> Thanks for testing! I agree that 0.5s period is probably on the low end.
> OTOH 8s seems a bit too much. Consider two bdi's with vastly different
> speeds - say their throughput ratio is 1:32 (e.g. an USB stick and a raid
> backed storage). When you write to the fast storage, then stop and start
> writing to the USB stick, then it will take 5 periods for bdi writeout
> ratio to become 1:1 and another 4-5 periods to be close to real current
> situation which is no IO to storage 100% io to USB stick. So with 8s period
> this will give you total transition time ~80s with seems like too much to
> me.
OK, got it.
> > Look at the gray "bdi setpoint" lines. The
> > VM_COMPLETIONS_PERIOD_LEN=8s kernel is able to achieve roughly the
> > same stable bdi_setpoint as the vanilla kernel, while being able to
> > adapt to the balanced bdi_setpoint much more fast (actually now the
> > bdi_setpoint is immediately close to the balanced value when
> > balance_dirty_pages() starts throttling, while the vanilla kernel
> > takes about 20 seconds for bdi_setpoint to grow up).
> Which graph is from which kernel? All four graphs have the same name so
> I'm not sure...
They are for test cases:
0.5s period
bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop+/balance_dirty_pages-pages+.png
3s period
bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop3+/balance_dirty_pages-pages+.png
8s period
bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.4.0-rc2-prop8+/balance_dirty_pages-pages+.png
vanilla
bay/JBOD-2HDD-thresh=1000M/xfs-1dd-1-3.3.0/balance_dirty_pages-pages+.png
> The faster (almost immediate) initial adaptation to bdi's writeout fraction
> is mostly an effect of better normalization with my patches. Although it is
> pleasant, it happens just at the moment when there is a small number of
> periods with non-zero number of events. So more important for practice is
> in my opininion to compare transition of computed fractions when workload
> changes (i.e. we start writing to one bdi while writing to another bdi or
> so).
OK. I'll test this scheme and report back.
loop {
dd to disk 1 for 30s
dd to disk 2 for 30s
}
Thanks,
Fengguang
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>