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

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

	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.

	To summarize:

	1: AMIX was pathetic in I/O for many more reasons than just it's 2k
	   page size.

	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.

		-Rob

------------------------------------------------------------------------------