From owner-svn-src-head@freebsd.org Wed Apr 20 15:17:07 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CEA5B166F0 for ; Wed, 20 Apr 2016 15:17:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 01D581307 for ; Wed, 20 Apr 2016 15:17:07 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x236.google.com with SMTP id gy3so131266256igb.0 for ; Wed, 20 Apr 2016 08:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=lhUzTdDwI7cD9KSKErake1VAyMvSEZiIPdmUTvsY07I=; b=JMngcPJxr7RMSDU33ZuSnDKltmRhhayLwR1tQm2y5m3dYVu0jP5ze+2ygIxrPh5Mik kmKYPzFc4XXZpNweT/X+5TclpfkTuvbbKG4ZxJznLdisg/3wM05+aNdzuopWelGMOPST R+vCuBK9b6uZI3w85S2sxevHGmcdjURVtzGowDYHGmkCHcE6YBzHbjlv+sVBv0H8Y5wS 7pITwT2+8UcKXJWfbtmcRua10nQxTabe34G13I7Ip3cY4iZLwyB3a7twQB7Cq6dLKox2 XL0VQRbDofzRKShOPNx+VJUEGG2fhezUFXl2N9SoVD+RcX5CvWguqAiBG+jOrA1qdMvZ 4SKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lhUzTdDwI7cD9KSKErake1VAyMvSEZiIPdmUTvsY07I=; b=LUrs94xMth4QqqB+HNSsFmvwQyX6f816C2blIX9thCZRwDK9m34755rEfTzMgqz2UO 7HPbe8nnIpSYWGZutbipfczCn+vxe9UhblX2Gg8CVTkLXz9IVp4Emc3bHQKdzH/Y9fCW PIF/CsfyFk24n/OXqSCDu3UWjzxCEzq9Wcu5Q3b6qiO8fMhv0+yGLdSpQjcv7LUoGynp 7pDmkmB6eBR6ZBl2gQYX8+Oh/0AeLlm1+J5V/zCyn0eFkPGFYtMrx6q2wjq35BqACELQ R0jWVByim9zISEn7EfTgnrXCfLSlPqSFXuvbroL9udpfBhGwLQr5bQr7hBJoaOCvA4cQ ZyLw== X-Gm-Message-State: AOPr4FVtXf6GhQKEcDiRUxgfs0q8G9y5vFnCSjkpQGfHTI+Uy9hTuBERorcX9lm08rekvpCxcQa49dav69kkzw== MIME-Version: 1.0 X-Received: by 10.50.110.99 with SMTP id hz3mr4139737igb.16.1461165426276; Wed, 20 Apr 2016 08:17:06 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.104.197 with HTTP; Wed, 20 Apr 2016 08:17:06 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160420084542.GC2422@kib.kiev.ua> References: <201604182309.u3IN9MC6047480@repo.freebsd.org> <57157108.6090500@freebsd.org> <20160419093022.GV2422@kib.kiev.ua> <5716538B.4060108@freebsd.org> <1461086958.1232.30.camel@freebsd.org> <20160420084542.GC2422@kib.kiev.ua> Date: Wed, 20 Apr 2016 09:17:06 -0600 X-Google-Sender-Auth: N7gBQ2QGjnkfHoTNua920uN4-H8 Message-ID: Subject: Re: svn commit: r298230 - in head: lib/libstand sys/boot/common sys/boot/efi/libefi sys/boot/efi/loader sys/boot/i386/libfirewire sys/boot/i386/libi386 sys/boot/i386/loader sys/boot/mips/beri/loader sy... From: Warner Losh To: Konstantin Belousov Cc: Ian Lepore , Allan Jude , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 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: Wed, 20 Apr 2016 15:17:07 -0000 On Wed, Apr 20, 2016 at 2:45 AM, Konstantin Belousov wrote: > On Tue, Apr 19, 2016 at 11:29:18AM -0600, Ian Lepore wrote: > > On Tue, 2016-04-19 at 11:49 -0400, Allan Jude wrote: > > > On 2016-04-19 05:30, Konstantin Belousov wrote: > > > > On Mon, Apr 18, 2016 at 07:43:04PM -0400, Allan Jude wrote: > > > > > On 2016-04-18 19:36, Adrian Chadd wrote: > > > > > > Someone pointed out how this bloats out memory requirement in > > > > > > loader. > > > > > > > > > > > > Did anyone check that? > > > > > > > > > > > > -adrian > > > > > > > > > > > > > > > > I tested down to 128mb of ram in QEMU, booted from the installer > > > > > ISO, > > > > > did the install, and booted the installed system without issue. > > > > > > > > 64MB is^H^H was very much useful and workable i386 config. i386 > > > > kernel > > > > does fit into the 32M but current automatic tuning prevents > > > > usermode > > > > from operating. Little manual tuning make 32M on tolerable. > > > > > > > > Making loader require 64M is a regression. At very least, it is > > > > impossible to test low mem configs anymore. > > > > > > > > > > Would a src.conf knob make sense, to use a smaller value when > > > targeting > > > small systems, while keeping the advantages when using more > > > reasonable > > > systems? > > > > > > Or we could make these changes to the HEAP and bcache size specific > > > to > > > 64bit platforms? > > > > > > > Exactly which "small systems" are we talking about here? From what I > > saw in the commit, all of this affects only i386 and amd64 and pc98 > > right now, not arm or mips or other systems that often have < 64MB ram. > > > > I take care of some really old legacy embedded systems at customer > > sites, and even so, with stuff dating back to the 2003-ish timeframe, > > the smallest i386 memory I have to deal with is 64MB. Are there really > > x86 systems that need to run in 32MB or less of ram these days, and use > > BIOS or EFI to boot? > Most of the VM/core system work is performed on the x86 machines, I mean > the debugging and testing, and not compiling. Consider this first-hand > experience. > > That is, not being able to check a change on 32MB x86 machine means, > for significant number of developers, that the change cannot be tested > on 32M machine at all. I leave the exercise of predicting the FreeBSD > behaviour on 32MB MIPS or ARM arches, after the x86 is left to require > 128MB at least for several months, to interested readers. > > What I wrote above is the only my concern, I do not know for sure if there > are any production-important installations where x86 FreeBSD of recent > versions run on, say, 64MB. As I noted elsewere, 64MB is enough to have > userspace fully operational. 32MB is not, but it is still useful for > kernel-only use. 32MB on arm is tight. Some heroics on tuning and you can still run on 32MB boards. But it is a lot of heroics, at least for ARM. Some minor tweaking gets 64MB to perform well, at least for the DNS / DHCP server I run on mine. Warner