From owner-svn-src-head@FreeBSD.ORG Tue Sep 2 20:02:54 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 409192AB; Tue, 2 Sep 2014 20:02:54 +0000 (UTC) Received: from pp1.rice.edu (proofpoint1.mail.rice.edu [128.42.201.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0005B1CAF; Tue, 2 Sep 2014 20:02:53 +0000 (UTC) Received: from pps.filterd (pp1.rice.edu [127.0.0.1]) by pp1.rice.edu (8.14.5/8.14.5) with SMTP id s82K2NK1009245; Tue, 2 Sep 2014 15:02:50 -0500 Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by pp1.rice.edu with ESMTP id 1p2u5b9r1g-1; Tue, 02 Sep 2014 15:02:50 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 7D0354C01D0; Tue, 2 Sep 2014 15:02:49 -0500 (CDT) Message-ID: <54062268.9060603@rice.edu> Date: Tue, 02 Sep 2014 15:02:48 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Steven Hartland , John Baldwin , Peter Wemm 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> <39211177.i8nn9sHiCx@overcee.wemm.org> <201409021201.15967.jhb@freebsd.org> <5405FD2C.8000901@rice.edu> <54060D1B.6020700@rice.edu> <774F8EEE96EB483DA8ACF533CF7C23F3@multiplay.co.uk> In-Reply-To: <774F8EEE96EB483DA8ACF533CF7C23F3@multiplay.co.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.601496849000349 urlsuspect_oldscore=0.00149684900034924 suspectscore=3 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.601496849000349 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409020210 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 20:02:54 -0000 On 09/02/2014 14:09, Steven Hartland wrote: > ----- 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? > Ah, I didn't see the uint64_t. I only looked at the calculation and assumed vm_offset_t was being used. So, yes, you are safe from overflow. > 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 > >