----- Original Message -----
From: "Peter Wemm" <pe...@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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
