> On Dec. 1, 2014, 5:37 p.m., Richard Elling wrote: > > I'd like to collaborate offline on this...
Sure thing, ping me on email or IM. - Matthew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/140/#review381 ----------------------------------------------------------- On Dec. 1, 2014, 4:05 p.m., Matthew Ahrens wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.csiden.org/r/140/ > ----------------------------------------------------------- > > (Updated Dec. 1, 2014, 4:05 p.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 c113b53a01755a0a3f3fb327151437aa9aef84db > > 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
