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

[John Baldwin]

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