On Thu, Apr 14, 2011 at 08:23:02AM +0800, Wu Fengguang wrote: > On Thu, Apr 14, 2011 at 07:52:11AM +0800, Dave Chinner wrote: > > On Thu, Apr 14, 2011 at 07:31:22AM +0800, Wu Fengguang wrote: > > > On Thu, Apr 14, 2011 at 06:04:44AM +0800, Jan Kara wrote: > > > > On Wed 13-04-11 16:59:41, Wu Fengguang wrote: > > > > > Reduce the dampening for the control system, yielding faster > > > > > convergence. The change is a bit conservative, as smaller values may > > > > > lead to noticeable bdi threshold fluctuates in low memory JBOD setup. > > > > > > > > > > CC: Peter Zijlstra > > > > > CC: Richard Kennedy > > > > > Signed-off-by: Wu Fengguang > > > > Well, I have nothing against this change as such but what I don't like is > > > > that it just changes magical +2 for similarly magical +0. It's clear that > > > > > > The patch tends to make the rampup time a bit more reasonable for > > > common desktops. From 100s to 25s (see below). > > > > > > > this will lead to more rapid updates of proportions of bdi's share of > > > > writeback and thread's share of dirtying but why +0? Why not +1 or -1? So > > > > > > Yes, it will especially be a problem on _small memory_ JBOD setups. > > > Richard actually has requested for a much radical change (decrease by > > > 6) but that looks too much. > > > > > > My team has a 12-disk JBOD with only 6G memory. The memory is pretty > > > small as a server, but it's a real setup and serves well as the > > > reference minimal setup that Linux should be able to run well on. > > > > FWIW, linux runs on a lot of low power NAS boxes with jbod and/or > > raid setups that have <= 1GB of RAM (many of them run XFS), so even > > your setup could be considered large by a significant fraction of > > the storage world. Hence you need to be careful of optimising for > > what you think is a "normal" server, because there simply isn't such > > a thing.... > > Good point! This patch is likely to hurt a loaded 1GB 4-disk NAS box... > I'll test the setup. Just did a comparison of the IO-less patches' performance with and without this patch. I hardly notice any differences besides some more bdi goal fluctuations in the attached graphs. The write throughput is a bit large with this patch (80MB/s vs 76MB/s), however the delta is within the even larger stddev range (20MB/s). The basic conclusion is, my IO-less patchset is very insensible to the bdi threshold fluctuations. In this kind of low memory case, just take care to stop the bdi pages from dropping too low and you get good performance. (well, the disks are still not 100% utilized at times...) Fluctuations in disk throughput and dirty rate and virtually everything are unavoidable due to the low memory situation. Thanks, Fengguang --- wfg ~/bee% cat xfs-1dd-1M-16p-5907M-3:2-2.6.39-rc3-dt7+-2011-04-14.22:40/iostat-avg avg-cpu: %user %nice %system %iowait %steal %idle sum 11.240 0.000 355.570 3244.380 0.000 9688.840 avg 0.085 0.000 2.673 24.394 0.000 72.848 stddev 0.034 0.000 0.323 2.184 0.000 2.367 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sum 0.000 46.000 0.000 23518.230 0.000 10712107.690 121079.620 5366.050 31005.460 828.630 12966.710 avg 0.000 0.346 0.000 176.829 0.000 80542.163 910.373 40.346 233.124 6.230 97.494 stddev 0.000 1.176 0.000 52.034 0.000 23800.746 5.447 14.554 103.214 2.964 8.123 wfg ~/bee% cat xfs-1dd-1M-16p-5907M-3:2-2.6.39-rc3-dt7+-2011-04-14.22:26/iostat-avg avg-cpu: %user %nice %system %iowait %steal %idle sum 13.550 0.000 239.960 3675.530 0.000 9370.930 avg 0.102 0.000 1.804 27.636 0.000 70.458 stddev 0.043 0.000 0.205 2.550 0.000 2.658 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sum 0.000 56.000 0.000 22294.270 0.000 10153687.050 121106.170 4764.470 28535.750 841.320 12993.110 avg 0.000 0.421 0.000 167.626 0.000 76343.512 910.573 35.823 214.555 6.326 97.693 stddev 0.000 1.209 0.000 44.869 0.000 20514.536 4.592 13.995 89.289 2.118 6.010 Thanks, Fengguang