On Fri, Feb 28, 2014 at 08:52:17AM -0800, Richard Elling wrote:
> I'm not 100% sure of the provenance of the ARC code in ZoL. Are you saying
> that the breakage is specific to ZoL and does not affect upstream? Or do youÂ
> believe the issues have been around for a long time?
The biggest breakage I think is specific to ZoL, but there's a few
subtle things that I've noticed and think are wrong in the code that is
shared between ZoL and upstream.
Specifically, things like this patch _might_ be helpful upstream:
* da8ccd0 Prioritize "metadata" in arc_get_data_buf
When the size limit is reached and when adding a metadata buffer to the
arc via arc_get_data_buf, a metadata buffer will be evicted. This is
whether arc_meta_used has reached arc_meta_limit or not. So it seems
like metadata can be "starved" as a result (i.e. it won't hit the
limit). If the metadata limit isn't reached yet, it makes sense (to me)
to pitch a data buffer instead.
Or this patch:
* 89c8cac Disable aggressive arc_p growth by default
When adding new anonymous data, if "arc_size" is less than "c" then "p"
will be increased. Why is that useful? That's not described in the
original ARC paper or in the code, and appears to starve to MFU for
certain workloads that I tested. What workloads does it help?
Or this one:
* 2b13331 Set "arc_meta_limit" to 3/4 arc_c_max by default
I hit a case where the ARC was filling up with mostly un-evictable
metadata buffers. This was due to the workload creating 4K files, each
file sitting in the dbuf cache holding it's dnode, which the dnode in
turn pinned the 16K dnode object buffer in the ARC. Is it "correct"? Is
it ok to let so much un-evictable metadata be resident in the ARC simply
because data is sitting in the upper layer dbuf cache? It definitely
makes it harder for us to implement a hard limit on the cached metadata
as we try to do on ZoL.
With all that said, all I really want to do is open up a discussion
about my changes with anybody who thoroughly understands the ARC code
and can answer some of my questions. I'm not completely sure my work is
"right", so I was hoping to hash some of the details out on this list.
--
Cheers, Prakash
_______________________________________________
developer mailing list
developer@open-zfs.org
http://lists.open-zfs.org/mailman/listinfo/developer
