> > 	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.
> 
> Don't think the page size can be ignored.. I did some experiments on SVR4
> trying to recombine pages submitted to the scsi driver, as long as they
> were contigous. Improvement was quite noticeable. Problem is, this
> wasn't always possible as page-in requests came in 2k chunks, and I could
> just be lucky if I could recombine 4 such requests into 1 8k job.
> 
	Wasn't too noticable with the drives I had to play with. Changing
	the ipl's around a bit helped some but without full source to
	the inturrupt system it was kinda unstable.

> > 	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.
> 
> *comfortly* run in 4M? come on.. hey, I worked with a PC linux with 4M,
> and that's in no way a comfortable way to work.. unless you enjoy watching
> your harddisk page all the time when editing...
> 
	Minus X you should be able to use the system in 4M comfortably,
	just because x86 linux has a shitty performance in 4M doesn't mean
	an m68k machine would. Right now a full bore kernel seems to
	pig about 3.5M, get that down to 2.5M and NetBSD use on a 4M
	system would be usable until X fired up... There's a major
	differnece with .5M phys mem left over and 1.5M physmem left over.

> > 	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
> Again, I don't think the sole difference of 4k to 8k pages will give you
> back 1M.
> 
	It would probably give back a significant chunk of it.

> SunOS is far from dead, considering the 2$#@$@ problems everyone has running
> Solaris.. as long as Sun can't provide an equally stable OS as SunOS, lots
> of people that don't HAVE to "upgrade" to Solaris, won't. (Still running
> all but one Sparc on 4.1.3, and the only reason one machine has to run
> Solaris is to run the ISDN software that doesn't run under 4.1.3:-(()
> 
	I run quite nicey at work on Solaris 2.3, in fact, it runs a HELL
	of alot better than the 4.1.3 systems. That some people don't
	know how to deal with SVR4 or patches doesn't mean the OS is
	useless. As of 2.3 all our 4.1.3 apps will actually run on
	Solaris 2.3, if only the license manager crap wasn't so braindead...

	I spent 9 hours adding patches to our main 4.1.3 system and it STILL
	has performance and functionality problems, after 95 patches! How
	anyone can say 4.1.3 is better than Solaris is beyond me. 4.1.3
	gives me much more grief that Solaris 2.3.

	SunOS m68k is very much dead; R.I.P. Try to get Sun or anyone else to
	give you a current version of anything in m68k SunOS format and
	they'll either give you the phone equivelent of a blank look or laugh
	at you. B^(. I can see why the SPARC people would want SunOS emulation,
	they can buy gobs of packages, but it seems of minimal use to m68k
	systems.

	A side issue is the rampent rumor that Sun will release 4.1.3 source to
	the world under a BSD like license now that they own all the source
	code in 4.1.3 and Solaris and can do whatever they damn well please
	with the source! They paid Novell about $83Million and the deal
	was finalized last Thursday. They'll probably only release the SPARC
	version tho from what I've heard.


> > 	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.
> 
> Why can't be do all of them? Improving pmap keeping 8k pages should be just
> as winning.
> 
	The internal page waste would still be high with 8k pages tho.

	Any chance we can make the page size optional? You choose 4k or
	8k at kernel compile time. Might be damn messy interchanging executables
	with different page sizes tho? This might help small systems out while
	still allowing big systems to get that last little bit of I/O
	performance out of the system at the cost of memory.

		-Rob

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