> On Dec. 1, 2014, 6:32 p.m., Steven Hartland wrote: > > 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.
Happy to. How can we make this more compatible with FreeBSD? I would think that the changes in arc_reclaim_thread() would be platform-independent, and those are really the key part of the improvement here. The changes to arc_reclaim_needed/arc_available_memory are really just for readability / debugability. - Matthew ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.csiden.org/r/140/#review383 ----------------------------------------------------------- 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
