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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 23, 2009 at 01:31:17PM +0800, Peter Zijlstra wrote:
> On Sun, 2009-08-23 at 09:32 +0800, Wu Fengguang wrote:
> > > > I'd propose to remove the above 'if' and liberate the following three 'if's.
> > > 
> > > That might work, but it looses the total dirty_thresh constraint. The
> > > sum of per-bdi dirties _should_ not be larger than that, but I'm not
> > > sure it won't ever be.
> > > 
> > > The clip code Richard removed ensured that, and I think I wrote that out
> > > of more than sheer paranoia, but I'm not sure anymore :/
> > 
> > Oh I assumed that your per-bdi throttling is not too permissive to
> > exceed the global dirty_thresh. In theory the per-bdi throttling
> > should be able to quickly stop the growing of (nr_reclaimable +
> > nr_writeback).  Once dirty_thresh is reached we already los
> 
> Right, so:
> 
>  bdi_thresh_n = dirty_thresh * p(n) + eps.
> 
> and
> 
>  \Sum_n p(n) = 1
> 
> So:
> 
>  \Sum_n bdi_thresh_n = dirty_thresh + n*eps
> 
> Which yields an O(n) error bound.
> 
> I'm just not sure how large the thing is in reality, and paranoia won
> out.

A wild question: is it possible to make the equation:

        bdi_thresh_n = dirty_thresh * p(n) - eps.

?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux