On Mon, Jun 11, 2001 at 03:01:28PM +0100, Ben Harris wrote:
> On Mon, 11 Jun 2001, Ian Fry wrote:
> > On Fri, Jun 08, 2001 at 08:10:10PM +0100, Ben Harris wrote:
> > > On Fri, 8 Jun 2001, Ian Fry wrote:
> > > > That's what I was going to try. IIRC, you run bb_riscbsd after using
> > > > HForm to setup the RISC OS side.
> > > Yeah, that's right.  All that stuff should work on NetBSD/arm26, since I
> > > share the arm32 disklabel-reading code.
> > Well, I didn't get that far, unfortunately :-( Here's a shortish summary of
> > what I have managed to do over the weekend.
> To be honest, I didn't think you would, but I think you've progressed
> quite a lot.

Yes, you did say you thought it'd be pushing it a bit when I first contacted
you...

> > Then I started experimenting with kernel options to try to trim the kernel
> > down. I looked at options(4), and found a few things to tweak (RASOPS_SMALL,
> > and things like NMBCLUSTERS). I had to patch rasops{2,4,8}.c to remove some
> > 'unused local' warnings before this would build.
> Could you send me those patches (or send-pr them)?

Yes, however they're quite simple - you just need to add '#ifndef
RASOPS_SMALL' around three declarations in each of those files.

> > Then I tried using 'nm' to find other things to trim - the biggest being
> > 'tcp_debug' (see netinet/tcp_debug.{c,h}). By default, there is a 100
> > element array of structures (presumably used to aim TCP debugging), so I
> > added 'options TCP_NDEBUG=n' for a few values of 'n' to my config, and
> > rebuilt the kernel again. Same result - VM shortage.
> Ooh.  I should add that to FOURMEG.

There may be a few more things like this that could be tuned, but tcp_debug
was the biggest culprit by far. I wonder if the tcp_debug stuff could be
optioned out altogether, including any code that is used?

> > With lots of experimenting, removing pseudo devices, changing config file
> > options (reducing the number of ptys etc), I got as far as having 2334K
> > of available memory when the kernel starts. Unfortunately, this is still
> > not enough to get to a single-user shell, and enable swapping (I setup a
> > 16M file in the NFS root with the intention of swapping to that file). I
> > once got as far as 'swapctl: adding /swap at priority 0', but the prompt
> > never returned.  Pressing Ctrl+T showed several (different) things,
> > normally that the kernel was in 'anonget2' or 'biowait'.
> Hmm.  I really feel that 2334K of user memory should be enough to get the
> world going, even with 32K pages.

Yes, me too. I was trying to get to around 2.5M, but 2334 was the best I
could do and still have NFS and FFS in the kernel. I even tried changing to
NFS_BOOT_BOOTP instead of NFS_BOOT_DHCP, but that didn't help much either.

> > So, I still can't quite get as far as being able to setup the hard drive.
> > I'll keep playing though, and if anybody has some ideas of what else I
> > can tune/trim I'll certainly try them out.
> One thing that David and I discussed at Wakefield was the possibility of
> replacing the kernel's malloc() with something a little more frugal.  The
> current one allocates one page for each power-of-two size of allocation
> from 16 bytes to a full page, which is a potential 320K wasted.  A noddy
> first-fit allocator (which could also avoid using KVM for small
> allocations) might help.

That's an idea - perhaps a different kernel allocator for small memory (or
large-page) machines.

> > PS I've found that I have to RMKill/Unplug the EtherH module under RISC
> > OS, as otherwise, the kernel doesn't always detect the card.
> Hmm.  Which version of EtherH is this?

The module? 4.19 I think, but I'd have to check. I think I might have a later
softload version downloaded from the Icubed website, but I haven't tried it.
It doesn't actually matter now that I've found that killing or unplugging the
module gets around the problem - I'm not planning on running RISC OS on this
machine all that much.

Ian.