From owner-svn-src-all@freebsd.org Wed Apr 20 08:45:52 2016 Return-Path: Delivered-To: svn-src-all@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 72435B156D2; Wed, 20 Apr 2016 08:45:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 033201B7F; Wed, 20 Apr 2016 08:45:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u3K8jgpL092793 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 20 Apr 2016 11:45:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u3K8jgpL092793 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u3K8jg7M092791; Wed, 20 Apr 2016 11:45:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Apr 2016 11:45:42 +0300 From: Konstantin Belousov To: Ian Lepore Cc: Allan Jude , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" 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... Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1461086958.1232.30.camel@freebsd.org> User-Agent: Mutt/1.6.0 (2016-04-01) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 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, 20 Apr 2016 08:45:52 -0000 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. > > On a related note, can this stuff be used for u-boot and other non-x86 > -BIOS flavors of loader(8)? If so, then a buildtime knob or the > ability to set the heap and/or cache size at runtime after figuring out > how much ram is available would be good features to have. > > -- Ian