From owner-svn-src-head@FreeBSD.ORG Tue Sep 2 19:09:13 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 C5D69B8B; Tue, 2 Sep 2014 19:09:13 +0000 (UTC) Received: from smtp1.multiplay.co.uk (smtp1.multiplay.co.uk [85.236.96.35]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA69154D; Tue, 2 Sep 2014 19:09:13 +0000 (UTC) Received: by smtp1.multiplay.co.uk (Postfix, from userid 65534) id E1EFA20E7088E; Tue, 2 Sep 2014 19:09:10 +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=1.0 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 ESMTP id 0C2CC20E7088C; Tue, 2 Sep 2014 19:09:09 +0000 (UTC) Message-ID: <774F8EEE96EB483DA8ACF533CF7C23F3@multiplay.co.uk> 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> <54060D1B.6020700@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 20:09:10 +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 19:09:14 -0000 ----- Original Message ----- From: "Alan Cox" > On 09/02/2014 12:34, Steven Hartland wrote: >> ----- Original Message ----- From: "Alan Cox" >>> 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. >> > > Is there any evidence that anything other than eliminating the KVA limit > is needed on machines where the page daemon isn't broken? In "my" direct experience, I would have to say no, I can't speak for others. >> It should be noted that for i386, as requested by Peter, this limitation >> has been re-applied. >> > > Unlike Solaris, we run on a few 32-bit architectures, besides i386, that > don't have a direct map or a full 4GB address space for the kernel. So, > for FreeBSD, this needs to be more general than just i386. I would > suggest using '#ifndef UMA_MD_SMALL_ALLOC' as being the closest thing > that we have to what you want here. This check will allow any machine, > including 32-bit machines that allocate some kernel memory through a > direct map, to opt out of the kmem map/arena/object limit. I'm not and don't profess to be an expert in this domain as you know ;-) So I'm to defer to you guys, Peter would you agree with this? > Finally, the Solaris KVA check is written to avoid the possibility of > integer overflow. However, the FreeBSD version is not. For example, > suppose that I setup an i386 machine with something approaching a > 2GB/2GB user/kernel split, 3 * kmem_size() could overflow. The returns of said functions are uint64_t so I'm not sure where the overflow would be when working with 2GB values? We seem to be missing some of the following, which doesn't impact us directly but may affect understanding of the "current" illumos code as its not in the tree: https://github.com/illumos/illumos-gate/commit/94dd93aee32d1616436eb51fb7b58094b9a8d3e8 Regards Steve