From owner-svn-src-all@freebsd.org Tue Apr 19 17:29:27 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 2F7ABB14B39 for ; Tue, 19 Apr 2016 17:29:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0D4BF19C7 for ; Tue, 19 Apr 2016 17:29:26 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 45fd5c2e-0654-11e6-8bda-c73aafa13d19 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 19 Apr 2016 17:29:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u3JHTIZW036206; Tue, 19 Apr 2016 11:29:18 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1461086958.1232.30.camel@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... From: Ian Lepore To: Allan Jude , Konstantin Belousov Cc: "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Date: Tue, 19 Apr 2016 11:29:18 -0600 In-Reply-To: <5716538B.4060108@freebsd.org> References: <201604182309.u3IN9MC6047480@repo.freebsd.org> <57157108.6090500@freebsd.org> <20160419093022.GV2422@kib.kiev.ua> <5716538B.4060108@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Tue, 19 Apr 2016 17:29:27 -0000 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? 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