bus dma: a flag/quirk for page zero
avg at FreeBSD.org
Wed Jan 11 17:34:51 UTC 2012
on 11/01/2012 18:02 Scott Long said the following:
> An old controller in the aac driver family had a variation of this problem back
> when the FreeBSD contigmalloc algorithm started from the bottom of memory
> instead of the top. I worked around it at driver init time by basically
> assuring that page 0 (and page 1) were allocated and thrown away; it seemed
> easier to leak 8k of memory than to jump through expensive hoops in busdma.
> The busdma filter is expensive, and is used so rarely that I'm not even sure it
> works. It was created for an old SCSI controller that had a buggy DMA
> controller which aliased a repeating pattern of address ranges; in other words
> it was a hack. It's expensive to use, since it forces every bus_dmamap_load()
> request through the slow path and possibly bouncing.
> With that said, your idea of a flag is probably a reasonable change for now.
> Alternatively, the ability to specify multiple DMA exclusion ranges has come up
> in the past, and would be a more complete answer to your problem; just treating
> page0 as special might not be enough (and I know for a fact that this is true
> with old i960RX pci processors). That'll involve an API change, so is
> something that I'd rather not happen on a whim.
thank you very much for the explanation and the insight.
As I've written in some other email, on x86 page 0 is already an "unavailable"
page and the only way it can get into the dma layer is only during a system dump.
I am not sure about all other platforms, probably there is at least one where page
0 is just another normal page. Maybe excluding page 0 from both normal use and
the dump is the most simple hummer for this nail...
The problem with trying to deal with page zero at the bus dma level is that it
pessimizes the cases where previously no bouncing was expected as page zero may
pop up anywhere. That's why I decided to go with the flag instead of handling
page 0 in all dma tags unconditionally as Matthew has suggested.
It feels like there could be a better solution that the flag, but I just can't
come up with it. To be fair, I haven't come up with the flag either, it's a
More information about the freebsd-current