Re: [VM PATCH 2.6.6-rc3-bk5] Dirty balancing in the presence of mapped pages

[Shantanu Goel]

--- Andrew Morton <akpm@xxxxxxxx> wrote:
> > > And what were the effects of this patch?

Below are some results of an iozone run on
ext3 with ordered data mode.  The machine is 2xXeon
with HT and 1.25GB of memory and a 15000rpm SCSI disk.

iozone was run with the following parameters:
  iozone -c -B -R -i 0 -r <record length> -s 1944978

The file size is 50% more than the amount of RAM.

2.6.6-rc3-bk5 stock (all KBytes):

        record        write        re-write
             4       110752           19143
             8       109818           17726
            16       112165           17053
            32       109824           17096

2.6.6-rc3-bk5 patched (all KBytes):

        record        write        re-write
             4       114284           17467
             8       117902           17149
            16       117835           18742
            32       118102           18961

Difference from stock (%):

        record        write        re-write
             4         +3.0             -8.7
             8         +7.3             -3.2
            16         +5.0             +9.9
            32         +7.5            +10.9

It seems this patch helps writes a bit but hurts
re-writes for smaller record sizes.  My guess is the
larger block size enables this patch to reduce the #
I/O requests.  I'll investigate this further and also
run the random write test when I get a chance.

> In this case, given that we have an actively mapped
> MAP_SHARED pagecache
> page, marking it dirty will cause it to be written
> by pdflush.  Even though
> we're not about to reclaim it, and even though the
> process which is mapping
> the page may well modify it again.  This patch will
> cause additional I/O.
> 

True, but is that really very different from normal
file I/O where we actively balance # dirty pages? 
Also, the I/O will only happen if the dirty thresholds
are exceeded.  It probably makes sense though to skip
SwapCache pages to more closely mimic file I/O
behaviour.

> So we need to understand why it was written, and
> what effects were
> observed, with what workload, and all that good
> stuff.
> 

My motivation was the NFS/WRITEPAGE_ACTIVATE
discussion and gobs of mmap'ed sequential writes.  If
we can detect dirty pages before they need to be
reclaimed and submit them for writeback, the NFS layer
will be hopefully be able to combine them into bigger
requests thereby reducing # RPCs.  This works well in
the file I/O case so I figured it might work equally
well in the mmap case.  The results are still pending
though.  I posted the patch to get feedback on whether
people see any fundamental flaw in this approach.

> > It doesn't do the wakeup_bdflush thing, but that
> sounds
> > like a good idea. What does wakeup_bdflush(-1)
> mean?
> 
> It appears that it will cause pdflush to write out
> down to
> dirty_background_ratio.

Yup, the idea is to mimic the balance_dirty_pages()
behaviour but not to force writes unless required by
the dirty ratios.

Thanks,
Shantanu



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover 
-
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/