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

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> 
>>Andrew Morton wrote:
>>
>>>Shantanu Goel <sgoel01@yahoo.com> wrote:
>>>
>>>
>>>>Presently the kernel does not collection information
>>>>about the percentage of memory that processes have
>>>>dirtied via mmap until reclamation.  Nothing analogous
>>>>to balance_dirty_pages() is being done for mmap'ed
>>>>pages.  The attached patch adds collection of dirty
>>>>page information during kswapd() scans and initiation
>>>>of background writeback by waking up bdflush.
>>>
>>>
>>>And what were the effects of this patch?
>>>
>>
>>I havea modified patch from Nikita that does the
>>if (ptep_test_and_clear_dirty) set_page_dirty from
>>page_referenced, under the page_table_lock.
> 
> 
> Dude.  I have lots of patches too.  The question is: what use are they?
> 
> 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.
> 
> So we need to understand why it was written, and what effects were
> observed, with what workload, and all that good stuff.
> 

I guess it is an attempt to do somewhat better at dirty page accounting
for mmap'ed pages. The balance_dirty_pages_ratelimited writeout path
also has the same problem as you describe. Maybe usage patterns means
this is less of an issue here?

But I suppose it wouldn't be nice to change without seeing some
improvement somewhere.

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

Yeah. So wakeup_bdflush(0) would be more consistent?