svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm

Nikolai Lifanov lifanov at mail.lifanov.com
Sun Sep 7 21:59:16 UTC 2014


On 2014-09-03 21:18, Steven Hartland wrote:
> ----- Original Message ----- From: "Andriy Gapon" <avg at FreeBSD.org>
> 
> 
>> on 03/09/2014 23:22 Nikolai Lifanov said the following:
>>> On 09/03/14 15:22, John Baldwin wrote:
>>>> On Wednesday, September 03, 2014 11:05:04 AM Nikolai Lifanov wrote:
>>>>> On 09/03/14 04:09, Steven Hartland wrote:
>>>>>> I'm looking to MFC this change so wanted to check if
>>>>>> anyone had an final feedback / objections?
>>>>>> 
>>>>>> I know we currently have Alan's feedback on changing
>>>>>> the #ifdef __i386__ to #ifndef UMA_MD_SMALL_ALLOC
>>>>>> which sounds sensible but waiting Peter to comment on.
>>>>>> 
>>>>>>    Regards
>>>>>>    Steve
>>>>> 
>>>>> I have no technical input, but this change improves ARC usefulness 
>>>>> for
>>>>> me quite a bit. I would like to see the improvement in 10-STABLE.
>>>> 
>>>> Can you verify that the current 10-STABLE (as of today) with all the 
>>>> various pagedaemon fixes still has ARC issues for your workload?
>>>> 
>>> 
>>> It doesn't have any issues, but I noticed the improvement on CURRENT. 
>>> I
>>> observed that just after this change, my package builder is much more
>>> likely to retain MFU and not evict useful things from there (the port
>>> tree) after large builds.
>>> However, I run a lot more 10.0-RELEASE than CURRENT and I would like 
>>> to
>>> see this improvement release-bound.
>>> 
>>> I would be happy to test this on 10-STABLE if you think that this is
>>> relevant.
>> 
>> 
>> As noted before, unfortunately, this commit (plus its fixups) contains 
>> at least
>> two related but distinct changes.  So, to separate the wheat from the 
>> chaff,
>> could you please try to comment out the following block in
>> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/arc.c, function 
>> arc_reclaim_needed:
>> 
>>        if (kmem_free_count() < zfs_arc_free_target) {
>>                DTRACE_PROBE2(arc__reclaim_freetarget, uint64_t,
>>                    kmem_free_count(), uint64_t, zfs_arc_free_target);
>>                return (1);
>>        }
>> 
>> Alternatively, I think that the same effect can be achieved by setting 
>> sysctl
>> vfs.zfs.arc_free_target to the same value as vm.stats.vm.v_free_min.
> 
> Thats correct that would achieve the same thing.
> 
>> It's interesting to me whether you would still see the better 
>> performance or if
>> that improvement would be undone.
> 
> Indeed that would be interesting, but we might find that its quite 
> memory size
> dependent given the scaling so confirming HW details would be nice too.
> 
> I'd also be interested to know who wins the free race between the VM 
> and ARC
> when using that value.
> 
> For those following this thread but not the review, I've added some 
> additional
> information there which you might be interested in:
> https://reviews.freebsd.org/D702
> 
>    Regards
>    Steve

I had time to re-test both the "stock" condition after the improvements 
and the condition in which 
vfs.zfs.arc_free_target=vm.stats.vm.v_free_min. It seems that MFU is 
more likely to be reduced in the second case.

- Nikolai Lifanov


More information about the svn-src-head mailing list