----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/140/#review383 -----------------------------------------------------------
I've yet to read this change set in full, but if we're looking to improve this area it would be good to look at making it more flexible / compatible with other OS's. One of the biggest issues FreeBSD sees with regards memory use of ZFS is related to tnis so collaborating on making this area more fitting would be a good start. - Steven Hartland 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
