Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc,comp.unix.bsd.netbsd.misc
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!spool.mu.edu!howland.reston.ans.net!swrinde!newsfeed.internetmci.com!news1.erols.com!news.enteract.com!news.inap.net!news1!not-for-mail
From: root@dyson.iquest.net (John S. Dyson)
Subject: Re: Curious about *BSD History
X-Nntp-Posting-Host: dyson.iquest.net
Message-ID: <4kp795$4fg@dyson.iquest.net>
Sender: news@iquest.net (News Admin)
Organization: John S. Dyson's Machine
References: <4k1nue$lm8@orb.direct.ca> <4kl863$rno@news.rhrz.uni-bonn.de> <1996Apr12.210743.28292@wavehh.hanse.de> <317006C4.77C0450E@lambert.org>
Date: Sat, 13 Apr 1996 21:45:09 GMT
Lines: 46
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:17275 comp.unix.bsd.netbsd.misc:2987
In article <317006C4.77C0450E@lambert.org>,
Terry Lambert <terry@lambert.org> wrote:
>
>I am more than passingly familiar with the 21066 Alpha boxes.
>
>Why do you think DMA transfers *always* require bounce buffers?
>
>Alpha needs bounce buffers for > 16M of memory -- but only in
>that case.
>
Sure sounds like the FreeBSD scheme slightly cleaned up (and it admittedly
needs it) would work.
>
>Like Amiga needs bounce buffers for "device accessable" vs.
>"device inaccessable" ("fast") RAM.
>
Again, it appears that the FreeBSD scheme would work here.
It is likely that NetBSD is creating a solution to a very very general
problem and likely unnecessarily complex in most cases.
The FreeBSD scheme simply pre-allocates a small amount of DMAable memory
for bouncing. In the case of the Alpha (as I can surmise from discussions
on the NetBSD mailing list) there might be sections of memory that are
accessible to/from only specific DMA channels/devices? If that is true,
only a slight generalization of the FreeBSD scheme might be needed. The
only problem with the FreeBSD scheme that is commonly agreed to is that
the resource allocation could be made cleaner (of course it would slow
the code down), by using some kind of resource map mechanism as opposed
to the hacked bit mechanism that I used. One could use either a private
vm_map mechanism (complex and general) or use a resource map like the
SVR4 (kernel) malloc or (Free,386)BSD's rlist stuff.
There have been some arguments that vtophys and associated mapping is one
of the major problems with the FreeBSD bouncing scheme. That does not
appear to be a bouncing problem, but simply a problem with a mapping mechanism
and perhaps a resource problem with mapping registers.
I used to run on a FreeBSD bounced system all of the time, and the small
pre-allocated memory did not ever appear to be a limiting factor either
because of excessive preallocation of memory or limited outstanding I/O.
John Dyson
dyson@freebsd.org