----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/140/#review417 -----------------------------------------------------------
Ship it! Ship It! - Steven Hartland On Dec. 18, 2014, 2:55 a.m., Matthew Ahrens wrote: > > ----------------------------------------------------------- > 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. > > > 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 > ----- > > 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
