My best guess would be that the thinking went: it's hard to evict metadata; hence implementing arc_meta_limit, so that we don't use all the ARC for metadata. If we let the arc size get down to 1/2 the meta_limit, then it's likely to be all filled with metadata, which is bad?
It's convoluted logic, to be sure, and I wouldn't defend it. --matt On Tue, Jan 21, 2014 at 6:02 AM, Andriy Gapon <[email protected]> wrote: > > Does anybody have an idea about why arc_c_min is pulled up to a half of > arc_meta_limit? > > if (arc_c_min < arc_meta_limit / 2 && zfs_arc_min == 0) > arc_c_min = arc_meta_limit / 2; > > It's not very obvious that zfs_arc_meta_limit tuning should have this > effect on > arc_c_min (if zfs_arc_min is not explicitly tuned). > > The code was added very long time ago and I can not see any explanation > for this > particular change in the commit that introduced arc_meta_limit: > > commit 0e8c61582669940ab28fea7e6dd2935372681236 > Author: maybee <none@none> > Date: Thu May 24 11:30:57 2007 -0700 > > 6542676 ARC needs to track meta-data memory overhead > 6544743 state->arcs_size >= state->arcs_lsize (0xe8046200 >= > 0xe8066200) > > P.S. > Why a default value of arc_meta_limit is 1/4th arc_c_max and, thus, why by > default arc_c_min ends up being 1/8th of arc_c_max is a different topic. > But, > IMHO, the following value, while as arbitrary, made more sense: > /* set min cache to 1/32 of all memory, or 64MB, whichever is more > */ > arc_c_min = MAX(arc_c / 4, 64<<20); > > -- > Andriy Gapon > > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer > >
_______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
