From owner-svn-src-head@freebsd.org Tue Apr 19 19:26:22 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 C1C1AB14C7F; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 A0BA7104C; Tue, 19 Apr 2016 19:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id BE3B2B9B2; Tue, 19 Apr 2016 15:26:21 -0400 (EDT) From: John Baldwin To: Konstantin Belousov 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... Date: Tue, 19 Apr 2016 09:26:41 -0700 Message-ID: <1769146.f6cP0aQdA7@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <20160419160500.GY2422@kib.kiev.ua> References: <201604182309.u3IN9MC6047480@repo.freebsd.org> <5716538B.4060108@freebsd.org> <20160419160500.GY2422@kib.kiev.ua> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 19 Apr 2016 15:26:21 -0400 (EDT) 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: Tue, 19 Apr 2016 19:26:22 -0000 On Tuesday, April 19, 2016 07:05:00 PM Konstantin Belousov wrote: > On Tue, Apr 19, 2016 at 11:49:31AM -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? > I do not consider neither the current state, nor the two proposed > changes, acceptable. Loader is same on 32 and 64 bit x86 machines, so > how would you reconfigure it on 64bit machine ? Non-default knob is too > obscure and hard to communicate, people would try to use 32M and see > that it breaks, just abandoning the idea of trying. > > Either default-built loader should size itself dynamically based on the > available memory, perhaps capping heap at 64MB starting from the 128MB > configs, or, assuming that we consider 32MB be the absolute minimal > workable config, loader could set HEAP to 8MB. > > Dynamic heap size is theoretically best, but it might be hard to do > if memory map is retrieved after heap is configured (I do not know). We retreive the memory map first and parse the SMAP to pick the best "spot" for the heap. (We prefer to put it "away" from the location where we load the kernel + modules.) Choosing a dynamic size for the heap should be quite doable. Fixing libstand's malloc() to try to "grow" when necessary would be nice for the EFI case as well, but that is a larger change. -- John Baldwin