Re: + mm-balance_dirty_pages-reduce-calls-to-global_page_state-to-reduce-c ache-references.patch added to -mm tree

[Wu Fengguang <fengguang.wu@intel.com>]

On Wed, Sep 02, 2009 at 06:45:24PM +0800, Peter Zijlstra wrote:
> On Wed, 2009-09-02 at 17:57 +0800, Wu Fengguang wrote:
> > On Wed, Sep 02, 2009 at 04:31:40PM +0800, Peter Zijlstra wrote:
> > > On Sat, 2009-08-22 at 20:11 +0200, Peter Zijlstra wrote:
> > > > > > +           /* always throttle if over threshold */
> > > > > > +           if (nr_reclaimable + nr_writeback < dirty_thresh) {
> > > > > 
> > > > > That 'if' is a big behavior change. It effectively blocks every one
> > > > > and canceled Peter's proportional throttling work: the less a process
> > > > > dirtied, the less it should be throttled.
> > > > 
> > > > Hmm, I think you're right, I had not considered that, thanks for
> > > > catching that.
> > > 
> > > So in retrospect I think I might have been wrong here.
> > > 
> > > The per task thing causes the bdi limit to be lower than the bdi limit
> > > based on writeback speed alone. That is, the more a task dirties, the
> > > lower the bdi limit is as seen for that task.
> > 
> > Right. If I understand it right, there will be a safety margin of about
> > (1/8) * dirty_limit for 1 heavy dirtier case, and that gap scales down
> > when there are more concurrent heavy dirtiers.
> 
> Right, with say 4 heavy writers the gap will be 1/4-th of 1/8-th, which
> is 1/32-nd.
> 
> With the side node that I think 1/8 is too much on large memory systems,
> and I have posted a sqrt patch numerous times, but I don't think we've
> ever found out if that helps or not...

Can you repost it?  I think sqrt-like curve is good for making the
real threshold more aligned with user expectations (vm_dirty_ratio and
especially vm_dirty_bytes). That should not create noticeable side
effects.

Thanks,
Fengguang