binary Mach distribution for 386

[lance.norskog]

rcd at ico.isc.com (Dick Dunn) writes:

>shore at mtxinu.COM (Melinda Shore) writes:

>> ...Also, you'd be surprised at how much
>> context switching can affect performance...

>That's actually less surprising in the 386 world.  Context switches on the
>386 (assuming a full switch--a TSS change via call gate) are relatively
>expensive, and interrupts are even worse because of the MM of dealing with
>the PICs.  Open question (I suspect): Is Mach 3.0 a bad match to the 386
>(based on context-switch frequency and cost)?

Well, there a few problems with standard UNIX on the 386 that
might go away with Mach:  

	1) UNIX re-uses the same kernel addresses for different processes.
	This forces UNIX to toss the page table cache during context
	switches, >when an operating system shouldn't have to<.  I
	don't believe the standard figure of 98% page table cache hits 
	for these systems.  Are there any hard studies of real code
	executing?
	
	2) UNIX still uses the PDP-11 interrupt hierarchy model.  The
	386 PIC code implements a faithful and extremely expensive
	emulation of this model.  

	Philips (Dutch) wrote a window manager for terminals as a 
	Streams multiplexor.  They found that 20% of the CPU time, 
	measured by a logic analyser, was spent in the interrupt 
	management code.  It would be quite easy to replace the
	hardware interrupt hierarchy with a software-based scheme
	where the only interrupt management is done with the
	enable/disable op codes.

	3) Use 4K blocks and fiddle page tables instead of copying
	data around.  The RAM situation that forced 1K blocks is
	over.  (If Intel still sold the DRAM chips they invented,
	it would have been 4K blocks from the beginning.)

Note to Benny: Any 386 UNIX port that uses the above tricks will 
leave the current crop in the dust.

Lance