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...

[Konstantin Belousov]

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