> 
> > 
> > 
> > I don't think that an OS should use kludges to make up for underlying
> > hardware limits, at least not on cheap, Intel commodity hardware.
> > 
> the "cludges" should be in the driver and thus would not affect the _os_.
> 
> > I take a certain interest in news postings that describe the bounce
> > buffer support in FreeBSD and Linux as performance killers.
> > 
> which in that case indicates that the implemented solution isn't
> very smart.... i can think of several ways of avoiding performance
> loss in most situations. at least with the current netbsd vm implementation.
> even if the solution is a performance killer, people with this kind of
> hardware can use the os. thats good for them. and good for the project.
>
I don't understand this statement.  The FreeBSD implementation exacts
a performance hit on a page-by-page basis only.  If the card does not
need bouncing, the overhead is only an if statement.  If the card
needs bouncing, the physical address of each page in the buffer is checked
(very low cost on an X86).  If no bouncing is needed, that is the extent
of the overhead.  If bouncing is required, the appropriate frobbing is
done to minimize copying.  Only pages that are not addressable in the
16MB are bounced.

The concept is simple, and SCSI device independent.  If the style of the
code is in question -- I might agree.  If the performance is in question, well,
show me the performance numbers, you won't see the hit as being signficant.
I cannot even see it on my 20MB 486/66 with a BT545S.  Memory to memory
copies on my system are about 29MBytes/sec.  My fastest drive is 3MBytes/sec.
I don't have to bounce *every* page in *every* buffer, or bounce *every*
page faulted into memory.

John Dyson
dyson@freebsd.org


John Dyson