Subject: Re: pages.
To: None <email@example.com>
From: Rob Healey <firstname.lastname@example.org>
Date: 03/19/1994 11:38:11
> 4k is the only one supported by the *86 as far as I know, so they didn't
> really do a terrific design decision chosing it.. The hp300 port uses 4k
> to be compatible to HPUX. SunOS uses 8k pages. There is a big advantage
> to 8k pages, too: 8k is one block in a usual ufs/nfs filesystem, improving
> hd i/o performance. I worked with Amiga Unix, using 2k pages, and it's i/o
> performance *SUCKS*.
Markus, we both know the real reason for the AmigaUNIX I/O sucking
is the terrible SCSI and inturrupt system. The page size is a drop
in the bucket compared to the other glaring deficiancys.
> I'd rather have a fast system at the cost of slight waste of memory,
> than a crawling one using every bit of available memory.
You call pissing away 1M of memory a "slight" waste of memory!?!?!?
I'd call that a big fork()ing memory PIG!
> Come on.. Amiga Unix is pretty dead, NetBSD runs on >= #machines that
> were able to run Amiga Unix. I don't consider Linux to be a threat to the
> amiga, why shouldn't you let people chose whatever OS they'd like to run?
> I certainly don't want to compromise NetBSD by Linux'isms just to get one
> or two of potential Linux users 'back' to NetBSD.
I agree NetBSD is in no danger from Linux but I also think using
the 8k page size causes too much internal memory waste. I'd
be willing to take the I/O hit for 4k, I don't think it's going to
be THAT bad, in trade for allowing many more smaller Amiga setups
to join the NetBSD throng.
With an IDE driver and the ability to comfortably run in 4M of
fast I think we would all be pleased at the number of new NetBSD
people we could pick up. We all know the more people involved
the better it is.
> Interesting! BTW: please, if you're already thinking into pmap internals,
> consider how to best support the huge address space open to Zorro3 boards,
> too. You'd not want to map this space hardwired like with Z2.. And for 4k:
> I think hp300 and even the mac-port are at least considering switching to
> 8k, please don't stop this process...
I agree about ZorroIII, it should be a part of the new pmap design.
The hp300 and Mac people would be fools to waste 1M of memory
for an incremental improvement in I/O. None of the m68k machines
can REALLY afford to piss away 1M or more of memory on internal
> To resume: I think the idea of having NetBSD run on small-memory amigas is
> a good idea. As long as this support doesn't compromise performance of amigas
> that are better suited to run a unix than any 2M machine could. Don't slow
> 16M amigas down, just to also be able to support 2M amigas.
I think the I/O hit from a 4k page size will be minimal if you
take the time to think out the I/O buffer management CAREFULLY.
Begin soapbox speech:
So, let's get to the REAL reason you don't want a 4k page size:
It would mess up SunOS emulation!
To this I say:
This is NetBSD, NOT SunOS DAMNIT! Why should we braindamage NetBSD
for a dead OS like m68k SunOS? I see no good reason for it. The only
reason I can think of is commercial applications, everything else
can be recompiled, and all the commercial vendors I've called have
basically laughed in my face when I asked for a Sun3 version of
WP, 123, database and a few other commercial packages I had to check
in to for Solaris migration at work. If you can get ahold of Sun 3
binarys more power to you but, at least in the US, it's a losing
How many people actually use Sun3 binarys on their Amiga's now that
most of the freely available software can be recompiled without a
lick of SunOS support in the kernel?
I think it is MUCH more valuable to bring in more Amiga owners and
bring in POSIX features than to try to keep compatable with a dead OS
like m68k SunOS.
End soapbox speech.
1: AMIX was pathetic in I/O for many more reasons than just it's 2k
2: 4k page size would reclaim 1M or more of memory and reduce internal
page waste by almost a half. This would allow more Amiga owners to
join the NetBSD cause.
3: Any I/O imact SHOULD be marginal as long as some thought it put in
to buffer management, i.e. fetching new pages in pairs for UFS
and NFS and handling the buffer pool. You'll also have to look
at DMA issues making sure you have two contiguous pages locked
down for raw low level I/O of 8k blocks.