svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

Slawa Olhovchenkov slw at zxy.spb.ru
Sun Sep 7 12:57:01 UTC 2014


On Fri, Sep 05, 2014 at 12:23:26PM +0300, Andriy Gapon wrote:

> on 04/09/2014 04:18 Steven Hartland said the following:
> > Indeed that would be interesting, but we might find that its quite memory size
> > dependent given the scaling so confirming HW details would be nice too.
> > 
> > I'd also be interested to know who wins the free race between the VM and ARC
> > when using that value.
> 
> BTW, I've written a small silly program that tests for a problem that affected
> me in the distant past: http://people.freebsd.org/~avg/arc-vs-swap.c
> 
> It gobbles almost all of the memory and then just sits on it never accessing it
> again.  At the same time it repeatedly reads blocks of data from a large file.
> The idea is that eventually the unused memory should be pushed out to the swap
> and the ARC is allowed to grow to accommodate for the data being read.
> 
> I run this program on a freshly booted system without any other applications.
> Prior to r270759 the system behaves as expected.  Although the pace of shifting
> balance between the ARC and the swap-backed pages is quite slow.
> After r270759 and with the default tuning the ARC always sits at its minimum
> size.  To me this is a regression.
> 
> To summarize: I really appreciate the improvements that you are making here
> https://reviews.freebsd.org/D702
> Thanks!
> 
> P.S.
> I wish there was an easy way to make the page cache and the ARC aware of each other.

I think no single way for any workload.
For some workloads ARC is prefered.
For some -- RSS is prefered.
May be need some tunable for elastics factor ARC/RSS?

PS: very bad that 'data limit' don't anymore reflect application
memory consumer. and very small application can adapt to 'no memory'
from system.


More information about the svn-src-all mailing list