Date: Sat, 26 Apr 2003 14:09:13 +0300 From: Ruslan Ermilov <ru@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: i386/loader compiled with NOFORTH Message-ID: <20030426110913.GB9189@sunbay.com> In-Reply-To: <XFMail.20030425164921.jhb@FreeBSD.org> References: <20030425202941.GD28920@sunbay.com> <XFMail.20030425164921.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--OwLcNYc0lM97+oe1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Apr 25, 2003 at 04:49:21PM -0400, John Baldwin wrote:
> On 25-Apr-2003 Ruslan Ermilov wrote:
> > But if we manage to load kernel high, above 1M, there
> > should be something that allows us to relocate heap
> > there, no? Also, can't we just trust what BIOS thinks
> > about the amount of memory?
>=20
> We load the kernel into lower memory first and then copy it
> up above 1mb. The memory above 1mb is not managed by the
> heap and is only used as the destination of the kernel.
>=20
I understand that this is how it works now.
> We could trust what the BIOS says, but putting the heap up
> above 1mb has some sticky issues. First off, where do we
> put it? We can't put it at 1m cause the kernel has to go
> there. If we stick it at 4m, then we've limited the kernel
> to only being 3m in size, adn GENERIC is already larger than
> that. Any kernel modules get loaded up above 1m as well,
> along with splash screens, etc. Do you want to set a max
> size for all that and stick the extra heap above there?
> You would need at least an extra meg of space for it to buy
> you anything, so let's say you limit the kernel + modules
> + module data size to 6mb, then you can start the extra
> heap at 7mb and still work on an 8bm machine. The loader
> would no longer _function_ on a 4mb machine. I really would
> like to have the loader function on a fairly broad range of
> machines.
>=20
Well, hm, the installation requirement was always slightly
larger than operational, so requiring 8MB for installation
is normal. The "normal" loader can still have its heap
pool in real-mode 1MB, but the "install" loader would
benefit from using say 900K for bzip2 plus the current heap
of 512K, at the top of available memory. Just like we
"load" kernel and other modules there, we could modify heap
routines to operate in upper memory, no? Is this handled
by the i386_copy{in,out} stuff in sys/boot/i386/libi386?
> I guess the real reason for your questions is that bzip2
> requires some outrageous amount of memory for some internal
> tables? Does bzip2 really buy us that much more space than
> gzip in this case?
>=20
Here are the 5.0-R numbers, from kern.flp and mfsroot.flp:
-r-xr-xr-x 1 root wheel 1310896 Jan 17 00:45 kernel.gz
-r-xr-xr-x 1 root wheel 1247884 Apr 26 14:00 kernel.bz2
-rw-r--r-- 1 root wheel 1407218 Jan 17 00:39 mfsroot.gz
-rw-r--r-- 1 root wheel 1358835 Apr 26 14:01 mfsroot.bz2
That is, saves us 50-60K of space on 1.44MB floppies.
Cheers,
--=20
Ruslan Ermilov Sysadmin and DBA,
ru@sunbay.com Sunbay Software AG,
ru@FreeBSD.org FreeBSD committer,
+380.652.512.251 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
--OwLcNYc0lM97+oe1
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
iD8DBQE+qmjZUkv4P6juNwoRAlCbAJ9MifRJQZa3u+9wDyrpNeYKJ5iTKQCbBj73
PEuzpRAk4cO1uIH44hYRmI8=
=GtmS
-----END PGP SIGNATURE-----
--OwLcNYc0lM97+oe1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030426110913.GB9189>