Subject: Re: BUFFERCACHE, PR 1903 + tangent: bounce buffers.
To: None <Chris_G_Demetriou@ux2.sp.cs.cmu.edu, michaelv@mindbender.serv.net>
From: Grey Wolf <greywolf@siva.captech.com>
List: current-users
Date: 09/16/1996 10:28:49
# From Chris_G_Demetriou@ux2.sp.cs.cmu.edu Fri Sep 13 20:58:03 1996
#
# 	(4) it's annoying to no longer be able to have the "N percent
# 	    of the first M megs, P percent of the rest" function,
# 	    to better support small-memory systems.

This would be a bad thing to lose.

# 
# 	(5) if the user specifies an out-of-range value:
# 		(a) it should not be silently adjusted, in my opinion
# 		    (i.e. issue a #warning), and
# 		(b) (in my opinion) if you are going to adjust it, i'd
# 		    say it should be clamped, not reset,  i.e. if < 5
# 		    then it's 5, and if > 95 then it's 95...  of
# 		    course, if you're issuing a warning, this isn't
# 		    nearly as important, and may just be a waste of
# 		    code.
# 			
# 

Is any attention being paid to

	(6) the VM and buffer caches need to be merged? "-)

# 


[Just checking; this has been bandied about -- or had been, anyway --
 and I'm curious as to where we are on this...]

# cgd
# 

Tangentially....

Someone made the claim that bounce-buffers need to be supported in a MI
fashion.  What other machines besides an ISA x86 box make use of boards
which need to DMA more than 16MB of core? [Chris, was this you?]
I mean the alphas and the HP9000 series (for which we don't yet have
a port) have ISA busses in them -- or some of them do.  But are bounce
buffers CRITICAL to their success?

Just wondering, because it seems that the only one which needs DMA for
things like disk access (something REAL important) is the x86.  I think
we should probably stick bounce-buffering into the x86 and be done with it.

I'm sure that if I'm blowing smoke, someone will be sure to let me know,
but before you flame me, forgive me if I don't have a firm grasp on the
details.  It just seems to me that to go MI _right now_ for bounce buffering
seems a bit overblown for our current needs:  It's more effort to do a
MI version than to do a port-specific version, and there's one port which
needs it more than the others, to the extent that NOT having it is causing
much unnecessary suffering.  I agree with the premise that one should NOT
have to buy all new hardware when there is only one component that imposes
a restriction.

				--*greywolf;