From owner-svn-src-head@FreeBSD.ORG Tue Sep 2 17:34:59 2014 Return-Path: Delivered-To: svn-src-head@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 636D248E; Tue, 2 Sep 2014 17:34:59 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 225CA1AC4; Tue, 2 Sep 2014 17:34:58 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id 6D0E520E7088F; Tue, 2 Sep 2014 17:34:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.multiplay.co.uk X-Spam-Level: ** X-Spam-Status: No, score=2.2 required=8.0 tests=AWL,BAYES_00,DOS_OE_TO_MX, FSL_HELO_NON_FQDN_1,RDNS_DYNAMIC,STOX_REPLY_TYPE autolearn=no version=3.3.1 Received: from r2d2 (82-69-141-170.dsl.in-addr.zen.co.uk [82.69.141.170]) by smtp1.multiplay.co.uk (Postfix) with ESMTPS id F11B520E7088C; Tue, 2 Sep 2014 17:34:53 +0000 (UTC) Message-ID: From: "Steven Hartland" To: "Alan Cox" , "John Baldwin" , "Peter Wemm" References: <201408281950.s7SJo90I047213@svn.freebsd.org> <39211177.i8nn9sHiCx@overcee.wemm.org> <201409021201.15967.jhb@freebsd.org> <5405FD2C.8000901@rice.edu> Subject: Re: svn commit: r270759 - in head/sys: cddl/compat/opensolaris/kern cddl/compat/opensolaris/sys cddl/contrib/opensolaris/uts/common/fs/zfs vm Date: Tue, 2 Sep 2014 18:34:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-15"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dmitry Morozovsky , "Matthew D. Fuller" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 17:34:59 -0000 ----- Original Message ----- From: "Alan Cox" > On 09/02/2014 11:01, John Baldwin wrote: >> On Saturday, August 30, 2014 1:37:43 pm Peter Wemm wrote: >>> On Saturday 30 August 2014 02:03:42 Steven Hartland wrote: >>> I'm very disappointed in the attention to detail and errors in the commit. >>> I'm almost at the point where I want to ask for the whole thing to be backed >>> out. >> I would not be too supportive of that. This PR has been open for a long, long >> time with many users using patches from it in production loads that were >> greatly improved by the changes and clamoring on the lists multiple times to >> get someone to look at it. avg@ contributed quite a bit of time to diagnose >> this with Karl early on, but other developers aside from Steven did not. It >> also was not hard to explain to Karl the meaning of 'cache + free' in the bug >> follow-ups itself (though I believe avg@ had tried this before and it didn't >> sink in that time for some reason). >> >> I know Steven has since committed a fix, but if there are still concerns, I >> think it would be best to not just revert this entirely but to spend some time >> fixing the remaining issues. Clearly this issue affects a lot of users and >> the earlier fixes to pagedaemon were not sufficient to fix their issues alone. >> > > The patch actually makes two completely orthogonal changes at once, and > one of those changes has no connection to the page daemon. I suspect > that is why some people have said that their issues were not addressed > by the page daemon fix. > > Prior to this patch, we were limiting the ARC size to 3/4 the kmem > map/arena/object size on all architectures, including 64-bit, > uma_small_alloc-enabled architectures where such a limit makes no > sense. Consequently, some people were complaining, "Why is 1/4 of my > memory going unused?" This is exactly the problem which lead me into investigating the issue. It should be noted that for i386, as requested by Peter, this limitation has been re-applied. Regards Steve