-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.csiden.org/r/140/
-----------------------------------------------------------
(Updated Dec. 18, 2014, 2:55 a.m.)
Review request for OpenZFS Developer Mailing List.
Changes
-------
feedback from richard
Bugs: 5376
https://www.illumos.org/projects/illumos-gate//issues/5376
Repository: illumos-gate
Description
-------
5376 arc_kmem_reap_now() should not result in clearing arc_no_grow
Reviewed by: George Wilson <[email protected]>
Reviewed by: Christopher Siden <[email protected]>
Original author: Matthew Ahrens
I observed a machine writing data at 200-500MB/s.
mpstat showed that periodically one CPU would become 100% busy for a few
seconds, with heavy crosscall activity. Sometimes the other CPUs would become
idle during this time. I discovered that this was due primarily to
arc_kmem_reap_now()'s calls to kmem_cache_reap_now(), and resulting TLB
shootdowns to remove mappings for freed slabs. There are many opportunities to
improve the kmem/vmem/hat code. However, upon reproducing the issue, I found
that ZFS's
ARC management can also be improved to reduce the frequency and duration of
these xcall storms. The primary observation is that we should not clear
arc_no_grow after calling arc_kmem_reap_now(). One way to prevent this would
be to have an idea of when we are getting low on memory before we actually have
to call arc_kmem_reap_now(), to not allow arc_no_grow to be cleared when we are
low on memory, and to ensure that arc_shrink() will keep us in the "low on
memory" region in the absence of other interactions. Implementing this fix
resulted in much less frequent calls to arc_kmem_reap_now() under a synthetic
workload.
Diffs (updated)
-----
usr/src/uts/common/fs/zfs/arc.c 435096becc75fa0a519424fbe8bd69e4cd2dc50c
Diff: https://reviews.csiden.org/r/140/diff/
Testing
-------
ztest
zfs test suite
running in production on NFS servers
Thanks,
Matthew Ahrens
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
