From owner-svn-src-all@FreeBSD.ORG Wed Sep 3 21:01:48 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93F8591D; Wed, 3 Sep 2014 21:01:48 +0000 (UTC) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2D8631519; Wed, 3 Sep 2014 21:01:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA18421; Thu, 04 Sep 2014 00:01:24 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1XPHgC-000HFw-HD; Thu, 04 Sep 2014 00:01:24 +0300 Message-ID: <5407816B.9000401@FreeBSD.org> Date: Thu, 04 Sep 2014 00:00:27 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nikolai Lifanov , John Baldwin Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm 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> In-Reply-To: <540778A2.3080809@mail.lifanov.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 03 Sep 2014 21:56:47 +0000 Cc: src-committers@FreeBSD.org, Peter Wemm , Alan Cox , svn-src-all@FreeBSD.org, Dmitry Morozovsky , "Matthew D. Fuller" , Steven Hartland , 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: Wed, 03 Sep 2014 21:01:48 -0000 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. It's interesting to me whether you would still see the better performance or if that improvement would be undone. Thanks! -- Andriy Gapon