From owner-svn-src-all@FreeBSD.ORG Sun Sep 7 21:59:16 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D12CFECE; Sun, 7 Sep 2014 21:59:15 +0000 (UTC) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AAD8E11F0; Sun, 7 Sep 2014 21:59:15 +0000 (UTC) Received: by mail.lifanov.com (Postfix, from userid 58) id F2A8D1B327A; Sun, 7 Sep 2014 17:59:08 -0400 (EDT) Received: from app.lifanov.com (chat.lifanov.com [206.125.175.13]) by mail.lifanov.com (Postfix) with ESMTPA id 03B801B1A4F; Sun, 7 Sep 2014 17:59:05 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 07 Sep 2014 17:59:05 -0400 From: Nikolai Lifanov To: Steven Hartland Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm In-Reply-To: <86292055B4114529874B693EEB441CB6@multiplay.co.uk> References: <201408281950.s7SJo90I047213@svn.freebsd.org> <169C94ED141B435BACEADB04A4824717@multiplay.co.uk> <54072E20.10802@mail.lifanov.com> <2230377.GgKARkJyaG@ralph.baldwin.cx> <540778A2.3080809@mail.lifanov.com> <5407816B.9000401@FreeBSD.org> <86292055B4114529874B693EEB441CB6@multiplay.co.uk> Message-ID: <68e46bf0acca7eb6417cb847267f7bff@mail.lifanov.com> X-Sender: lifanov@mail.lifanov.com User-Agent: Roundcube Webmail/1.0.2 X-Mailman-Approved-At: Mon, 08 Sep 2014 20:39:19 +0000 Cc: src-committers@freebsd.org, Peter Wemm , John Baldwin , Alan Cox , svn-src-all@freebsd.org, Dmitry Morozovsky , Andriy Gapon , "Matthew D. Fuller" , svn-src-head@freebsd.org, owner-svn-src-head@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Sep 2014 21:59:16 -0000 On 2014-09-03 21:18, Steven Hartland wrote: > ----- Original Message ----- From: "Andriy Gapon" > > >> 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