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

[Bill Davidsen <davidsen@tmr.com>]

Nick Piggin wrote:

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

Lots of issues here, writing in random blocks can lead to fragmentation 
if the data is newly allocated, but won't change fragmenting if the page 
mapped is alread allocated on the disk.

Is it practical or desirable to be writing mapped pages of allready 
allocated files back more readily, since it avoid all the allocation 
issues? But you still need to limit dirty pages, so at some point it 
will be necessary to do the allocation, preferably in an optimal way.

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

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979