Date: Fri, 29 Aug 2014 21:42:15 +0100 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Peter Wemm" <peter@wemm.org> Cc: src-committers@freebsd.org, Alan Cox <alc@rice.edu>, svn-src-all@freebsd.org, Dmitry Morozovsky <marck@rinet.ru>, "Matthew D. Fuller" <fullermd@over-yonder.net>, svn-src-head@freebsd.org Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm Message-ID: <0B77E782B5004AEBA77E6A5D16924D83@multiplay.co.uk> References: <201408281950.s7SJo90I047213@svn.freebsd.org> <1592506.xpuae4IYcM@overcee.wemm.org> <5A300D962A1B458B951D521EA2BE35E8@multiplay.co.uk> <64121723.0IFfex9X4X@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message -----
From: "Peter Wemm" <peter@wemm.org>
> On Friday 29 August 2014 20:51:03 Steven Hartland wrote:
snip..
> > Does Karl's explaination as to why this doesn't work above change
> > your
> > mind?
>
> Actually no, I would expect the code as committed would *cause* the
> undesirable behavior that Karl described.
>
> ie: access a few large files and cause them to reside in cache. Say
> 50GB or so
> on a 200G ram machine. We now have the state where:
>
> v_cache = 50GB
> v_free = 1MB
>
> The rest of the vm system looks at vm_paging_needed(), which is: do
> we have
> enough "v_cache + v_free"? Since there's 50.001GB free, the answer is
> no.
> It'll let v_free run right down to v_free_min because of the giant
> pool of
> v_cache just sitting there, waiting to be used.
>
> The zfs change, as committed will ignore all the free memory in the
> form of
> v_cache.. and will be freaking out about how low v_free is getting and
> will be
> sacrificing ARC in order to put more memory into the v_free pool.
>
> As long as ARC keeps sacrificing itself this way, the free pages in
> the v_cache
> pool won't get used. When ARC finally runs out of pages to give up to
> v_free,
> the kernel will start using the free pages from v_cache. Eventually
> it'll run
> down that v_cache free pool and arc will be in a bare minimum state
> while this
> is happening.
>
> Meanwhile, ZFS ARC will be crippled. This has consequences - it does
> RCU like
> things from ARC to keep fragmentation under control. With ARC
> crippled,
> fragmentation will increase because there's less opportunistic
> gathering of
> data from ARC.
>
> Granted, you have to get things freed from active/inactive to the
> cache state,
> but once it's there, depending on the worlkload, it'll mess with ARC.
There's already a vm_paging_needed() check in there below so this will
already
be dealt with will it not?
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0B77E782B5004AEBA77E6A5D16924D83>