svn commit: r304187 - in head: . share/man/man4 sys/conf sys/dev/mcd sys/modules sys/modules/mcd

Bruce Evans brde at optusnet.com.au
Fri Aug 19 11:13:31 UTC 2016


On Fri, 19 Aug 2016, Konstantin Belousov wrote:

> On Thu, Aug 18, 2016 at 09:28:57PM -0600, Warner Losh wrote:
>> On Thu, Aug 18, 2016 at 12:50 AM, Julian Elischer <julian at freebsd.org> wrote:
>>> On 16/08/2016 4:54 AM, John Baldwin wrote:
>>>>
>>>> On Monday, August 15, 2016 08:38:02 PM John Baldwin wrote:
>>>>> ,,,
>>>>> Log:
>>>>>    Remove the mcd(4) driver for Mitsumi CD-ROM players.
>>>>>       This is a driver for a pre-ATAPI ISA CD-ROM adapter.  As noted in
>>>>>    the manpage, this driver is only useful as a backend to cdcontrol to
>>>>>    play audio CDs since it doesn't use DMA, so its data performance is
>>>>>    "abysmal" (and that was true in the mid 90's).
>>>>
>>>> No one stepped up to test patches for it either when I last posted patches
>>>> to
>>>> convert it from timeout(9) to callout(9).  I have a few more drivers that
>>>> are
>>>> ...
>>>
>>> I would imagine any machine still holding one of these probably has not
>>> enough memory to run FreeBSD.
>>>
>>> would we still run in 2MB?
>>
>> With insane levels of tuning, we can run in 32MB userland that can do
>> things. Even 64MB is tight w/o some tuning. 16MB is almost certainly
>> right out except for very specialized situations. 2MB? We can't even
>> load the loader in that :(. Oh, and all these memory configs are only
>> possible if you tweak the loader's block cache...
>
> 32MB is quite usable.  Without any tuning, you get slightly less than 10MB
> for userspace, which is enough to for many things, and plenty if swap is
> added.

No, 32MB needs lots of needs tuning.  -current seems to need about 16MB
more than just a few months ago when I last discussed this with you.
My i386 system doesn't have many drivers or a bloated userland (*),
but it took the following tuning plus my PAE tuning fixes to boot in
32MB:
- disable [l]em1
- reduce tx and buffers to 256 for em0.  They default to 4096 for em.  That
   is something like 8K * 1500 bytes = 12MB for em0 alone.  lem[1] wants
   another 12MB.  I think this is not all statically allocated, but the
   drivers hang onto that much.
This now longer works.  -current without my PAE tuning fixes hangs mounting
root or in usb initialization with this tuning and 40MB.  -current with my
PAE tuning fixes hangs similarly with 32MB; with 40MB it boots to the
start of multiuser but then hangs (it starts 1 getty, then 2 sendmails
and kills them with "out of swap space") and 1 rpcbind (also killed).  I
don't use swap, but it was needed 20 years ago on a system that actually
had 32MB of memory.

(*) /bin/sh doing nothing much in -current i386: size 6532K res 1924K
     /bin/sh                    in my ~5.2  i386: size  864K res  592K

The kernel size is 5.5MB text 370K data 2.2MB bss (lots of bloat in bss
for debugging and vt).  In single user mode, with 40MB to start, there
is 22116K wired and 2516K free.  A few programs can be run in 2516K
without swap if they have res 592K and not 1924K.

> Note that you cannot boot on such configurations since loader was broken,
> but if you do manage to jump to kernel, things were fine several months
> ago.  I tested my relatively recent OOM changes on 32MB qemu config.

I have no problems booting such configuratations since I don't use the
current loader and only use old loader to change the environment to
set up special configurations like this.  I use my version of biosboot
for boot2.  This requires fixing 2 layers of complicated breakage in
init386().  vm86 is now used before the TSS and PIC resources that it
uses are initialized, but only in paths that are not normally used
because they are for memory sizing that is normally done by loader
:-(.

I normally use my version of biosboot for boot2.  I improved its caching
just a couple of years ago.  It was using 9K buffer optimized for 1440K
floppies.  Now it uses a 32K buffer.  Booting a 5.5MB kernel takes a
fraction of a second.  Of course I don't use modules, so not many seeks
are needed.

Bruce


More information about the svn-src-all mailing list