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

Dmitry Morozovsky marck at rinet.ru
Fri Apr 3 16:37:53 UTC 2015


Alexander,

On Fri, 3 Apr 2015, Alexander Motin wrote:

> Author: mav
> Date: Fri Apr  3 14:45:48 2015
> New Revision: 281026
> URL: https://svnweb.freebsd.org/changeset/base/281026
> 
> Log:
>   Make ZFS ARC track both KVA usage and fragmentation.
>   
>   Even on Illumos, with its much larger KVA, ZFS ARC steps back if KVA usage
>   reaches certain threshold (3/4 on i386 or 16/17 otherwise).  FreeBSD has
>   even less KVA, but had no such limit on archs with direct map as amd64.
>   As result, on machines with a lot of RAM, during load with very small user-
>   space memory pressure, such as `zfs send`, it was possible to reach state,
>   when there is enough both physical RAM and KVA (I've seen up to 25-30%),
>   but no continuous KVA range to allocate even single 128KB I/O request.
>   
>   Address this situation from two sides:
>    - restore KVA usage limitations in a way the most close to Illumos;
>    - introduce new requirement for KVA fragmentation, specifying that we
>   should have at least one sequential KVA range of zfs_max_recordsize bytes.
>   
>   Experiments show that first limitation done alone is not sufficient.  On
>   machine with 64GB of RAM it is sometimes needed to drop up to half of ARC
>   size to get at leats one 1MB KVA chunk.  Statically limiting ARC to half
>   of KVA/RAM is too strict, so second limitation makes it to work in cycles:
>   accumulate trash up to certain critical mass, do massive spring-cleaning,
>   and then start littering again. :)
>   
>   MFC after:	1 month

Wow.  Excellent dig, thank you.


-- 
Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------


More information about the svn-src-all mailing list