]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC r281026, r281108, r281109:
authormav <mav@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 3 May 2015 07:13:14 +0000 (07:13 +0000)
committermav <mav@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Sun, 3 May 2015 07:13:14 +0000 (07:13 +0000)
commit2b3be602c1d80d32780cb001861c60baea9895e7
tree9f6b4a3f884acdfc5f468ff0df0455f39af7dc78
parentb5fd96ae4c138e0b988f1dfb152bbce167d0dc1b
MFC r281026, r281108, r281109:
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.

git-svn-id: svn://svn.freebsd.org/base/stable/10@282361 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c
sys/kern/subr_vmem.c
sys/sys/vmem.h