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

[Warner Losh]

On Wed, Apr 20, 2016 at 2:45 AM, Konstantin Belousov <kostikbel at gmail.com>
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