lkml.org 
[lkml]   [2011]   [Sep]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 00/18] IO-less dirty throttling v11
Hi Christoph,

On Wed, Sep 28, 2011 at 10:58:57PM +0800, Christoph Hellwig wrote:
> On Sun, Sep 04, 2011 at 09:53:05AM +0800, Wu Fengguang wrote:
> > Hi,
> >
> > Finally, the complete IO-less balance_dirty_pages(). NFS is observed to perform
> > better or worse depending on the memory size. Otherwise the added patches can
> > address all known regressions.
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/wfg/writeback.git dirty-throttling-v11
> > (to be updated; currently it contains a pre-release v11)
>
> Fengguang,
>
> is there any chance we could start doing just the IO-less
> balance_dirty_pages, but not all the subtile other changes? I.e. are
> the any known issues that make things work than current mainline if we
> only put in patches 1 to 6?

Patches 1-6 are the bare IO-less framework, the followed patches are

1) tracing for easy debug
2) regression fixes (eg. under-utilized disk in small memory systems)
3) improvements

My recent focus is trying to measure and fix the various regressions.
Up to now the JBOD regressions have been addressed and single disk
performance also looks good.

NFS throughputs are observed to drop/rise somehow randomly in
different cases and cannot be fixed fundamentally with the trivial
approaches I've experimented.

3.1.0-rc4-vanilla+ 3.1.0-rc4-bgthresh3+ 3.1.0-rc4-nfs-smooth+
------------------ -------------------- ---------------------

3459793 -33.2% 2310900 +2.4% 3543478 NFS-thresh=1G/nfs-10dd-1M-32p-32768M-1024M:10-X
3371104 -32.8% 2265584 -13.9% 2902573 NFS-thresh=1G/nfs-1dd-1M-32p-32768M-1024M:10-X
2798005 +13.4% 3171975 +21.4% 3395410 NFS-thresh=1G/nfs-2dd-1M-32p-32768M-1024M:10-X

1641479 +13.9% 1869541 +52.7% 2506587 NFS-thresh=100M/nfs-10dd-1M-32p-32768M-100M:10-X
3036860 -19.4% 2447633 -32.1% 2063006 NFS-thresh=100M/nfs-1dd-1M-32p-32768M-100M:10-X
2050746 +19.8% 2456601 +28.4% 2634044 NFS-thresh=100M/nfs-2dd-1M-32p-32768M-100M:10-X

1042855 +2.7% 1070893 +0.9% 1052112 NFS-thresh=10M/nfs-10dd-1M-32p-32768M-10M:10-X
2106794 -41.6% 1231128 -54.6% 957305 NFS-thresh=10M/nfs-1dd-1M-32p-32768M-10M:10-X
2034313 -40.4% 1212212 -51.7% 982609 NFS-thresh=10M/nfs-2dd-1M-32p-32768M-10M:10-X

239379 0 +10.2% 263894 NFS-thresh=1M/nfs-10dd-1M-32p-32768M-1M:10-X
521149 -42.3% 300872 +13.9% 593485 NFS-thresh=1M/nfs-1dd-1M-32p-32768M-1M:10-X
564565 0 -49.6% 284397 NFS-thresh=1M/nfs-2dd-1M-32p-32768M-1M:10-X

> We're getting close to another merge window, and we're still busy
> trying to figure out all the details of the bandwith estimation. I
> think we'd have a much more robust tree if we'd first only merge the
> infrastructure (IO-less balance_dirty_pages()) and then work on the
> algorithms separately.

Agreed. Let me sort out the minimal set of patches that can still
maintain the vanilla kernel performance, plus the tracing patches.

Thanks,
Fengguang


\
 
 \ /
  Last update: 2011-09-29 06:13    [W:0.258 / U:6.540 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site