[lkml]   [2003]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] RFC: kills consistent_dma_mask
Pete Zaitcev <> 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:

using_dac = 1;
if (!pci_dma_supported(dev, 0xFFFFFFFFFFFFFFFF)) {
if (!pci_dma_supported(dev, 0xFFFFFFFF))
using_dac = 0;


foo = pci_alloc_consistent(pdev, size, &handle, 0xFFFFFFFF);
bar = pci_map_single(...,

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

> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.082 / U:4.712 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site