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

[Andrew Morton <akpm@osdl.org>]

Nikita Danilov <nikita@clusterfs.com> wrote:
>
> 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()?

ah, much less dirty memory around.  Yes, it might be something to do with
that.

The difference is so large that we really should understand the precise
reason rather than guessing though.  It might point at some problem in the
lru-based page-at-a-time writeback which we can fix.

>  > 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.

OK.  Sometimes writeback-off-the-lru goes poorly on SMP (half the speed)
due to the two CPUs performing writeout to different parts of the disk.  Or
something like that.  Just a simple memset(malloc(lots)) swapstorm
demonstrates it.


--
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>