Messages in this thread | | | Subject | Re: [PATCH] RFC: kills consistent_dma_mask | From | Krzysztof Halasa <> | Date | 18 Aug 2003 18:14:25 +0200 |
| |
Pete Zaitcev <zaitcev@redhat.com> writes:
> Are you talking about doing tripple calls, e.g. > > pci_set_dma_mask(pdev, 0xFFFFFFFF); > foo = pci_alloc_consistent(pdev, size, &handle); > // Restore for upcoming streaming allocations > pci_set_dma_mask(pdev, 0xFFFFFFFFFFFFFFFF); > > Possibly Jes considered that alternative and decided that it > did not allow for sufficient performance.
Possibly. Is that true?
I could imagine even something like that:
init_module() { using_dac = 1; if (!pci_dma_supported(dev, 0xFFFFFFFFFFFFFFFF)) { if (!pci_dma_supported(dev, 0xFFFFFFFF)) error; using_dac = 0; } }
...
foo = pci_alloc_consistent(pdev, size, &handle, 0xFFFFFFFF); bar = pci_map_single(..., using_dac ? 0xFFFFFFFFFFFFFFFF : 0xFFFFFFFF);
I don't think it would be slower. If inlined, if would be even faster.
However, the main problem is not that it isn't beautiful but rather that it's broken.
> Before you go for that, I'd rather see you implementing the > double/tripple calls in drivers, check for effects, THEN > go for removal of the mask.
The problem is that the official kernel does NOT contain any driver which needs different masks.
> > This patch doesn't actually change any current kernel behaviour. > > Sure it does. It blows all non-mmu ia64 out of the water.
No. The kernel (2.6.0-test3 at least) doesn't count on that under any circumstances.
> The consistent mask looks a little distasteful to me, and I think > it should not buy us performance because consistent allocations > are not supposed to be fast. They are bad, but what you are doing > is worse: you are trying to ruin the day of legitimate users.
Of course this isn't what I'm trying to do. -- Krzysztof Halasa Network Administrator - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |