Re: [PATCH]: VM 6/8 page_referenced(): move dirty

[Nikita Danilov <nikita@clusterfs.com>]

Andrew Morton writes:
 > Nikita Danilov <nikita@clusterfs.com> wrote:
 > >
 > > Andrew Morton writes:
 > >   > Nikita Danilov <nikita@clusterfs.com> wrote:
 > >   > >
 > >   > >   > 
 > >   > >   > I can envision workloads (such as mmap 80% of memory and continuously dirty
 > >   > >   > it) which would end up performing continuous I/O with this patch.
 > >   > > 
 > >   > >  Below is a version that tries to move dirtiness to the struct page only
 > >   > >  if we are really going to deactivate the page. In your scenario above,
 > >   > >  continuously dirty pages will be on the active list, so it should be
 > >   > >  okay.
 > >   > 
 > >   > OK, well it'll now increase the amount of I/O by a smaller amount.  Trade
 > >   > that off against possibly improved I/O patterns.  But how do we know that
 > >   > all this is a net gain?
 > > 
 > >  By looking at the (micro-) benchmarking results:
 > > 
 > >  2.6.12-rc2:
 > > 
 > >  before-patch page_referenced-move-dirty
 > > 
 > >          45.8  32.3
 > >         204.3  93.2
 > >         194.8  89.5
 > >         194.9  89.9
 > >         197.7  92.1
 > >         195.0  90.2
 > >         199.4  89.5
 > >         196.3  89.2
 > 
 > hm.  What's the reason for such a large difference?  That workload should

Early write-out from pdflush and balance_dirty_pages()?

 > just be doing pretty-much-linear write even if we're writing a
 > page-at-a-time off the tail of the LRU.
 > 
 > Was that box SMP?

Single P4 with HT; file system is ext3.

Nikita.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>