> > 
> And there is always swapping/paging too... mmapped files etc.
> As a matter of fact, iv'e implemented page shuffeling once just to improve
> on i/o performance by having contigous i/o areas in programs doing physical
> i/o. The performance gain was most noticable when doing tape i/o. Streaming
> tape drives really did 'stream'. Even if it wasn't a dmaable page issue it
> showed that doing something that looked 'heavy' gained in the long run.
> Not saying that a complicated bounce scheme would..
> 
You are making a interesting point.  I had simply assumed that scatter/gather
had little or no overhead -- maybe it does.

> 
> What is a fully optimal scheme? Would be hard to identify one. It's likely
> that a few things may be found that might help performance, for example
> migrating pages that stays in memory for long time to non dmaable pages.
>
When I used the term "fully optimal" I meant that if we did as much as
we could, then we would probably not see a significant enough performance
difference to make it worth while.  I have been wrong in the past though,
and maybe it would be worthwile to experiment.

>
> Perhaps that would be more effective than trying to 'guess' the usage for
> a page when allocating it... hmmm... preferably ronly pages... sooo maybe
> it's not worth moving pages around to be able to _do_ i/o on them but
> rather move pages around that are likely to _not do_ io on?
> 
You have made a very interesting point, and it is easier to a-priori guess
at page allocation time than to migrate the pages.  This might be worthwhile!

> 
> I think we both talk about the same solution, a simple straightforward
> bounce scheme for pages not dmaable, and direct dma to pages that is
> dmaable, right?
> 
Absolutely, and my initial thoughts (and what I had implemented on FreeBSD)
was to keep it as simple as possible.  I will NEVER forget how Jordan
coerced me to do it :-).  It was originally the most buggy code I had ever
written.  It certainly is not perfection.  If NetBSD looks at my scheme and
re-implements it more nicely, I would have no problem (NIH) grabbing the
nicer NetBSD code.

John Dyson
dyson@freebsd.org