> On Dec. 1, 2014, 5:37 p.m., Richard Elling wrote:
> > usr/src/uts/common/fs/zfs/arc.c, line 3846
> > <https://reviews.csiden.org/r/140/diff/1/?file=11840#file11840line3846>
> >
> >     ptob(physmem - swapfs_minfree)

done.


> On Dec. 1, 2014, 5:37 p.m., Richard Elling wrote:
> > usr/src/uts/common/fs/zfs/arc.c, line 2374
> > <https://reviews.csiden.org/r/140/diff/1/?file=11840#file11840line2374>
> >
> >     For posterity, I'd rather see the free_reason as a set of kstat 
> > counters. This will help forensics immensely by answering the question 
> > "have we ever been pressured by heap, zio, pp_max,... ?"
> >     
> >     I'd like to have this so much, that I'll offer to make the changes.

as discussed offline, that sounds fine, and can be added as a subsequent push 
whenever you're ready.


> On Dec. 1, 2014, 5:37 p.m., Richard Elling wrote:
> > usr/src/uts/common/fs/zfs/arc.c, line 184
> > <https://reviews.csiden.org/r/140/diff/1/?file=11840#file11840line184>
> >
> >     I'd prefer to see this as:
> >     arc_no_grow_shift = arc_shrink_shift - 2
> >     
> >     with appropriate bounds checking and override, ala zfs_arc_shrink_shift

Added code to ensure that arc_no_grow_shift is less than arc_shrink_shift.


- 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

Reply via email to