From: Jes Sorensen <jes@wildopensource.com>
To: Krzysztof Halasa <khc@pm.waw.pl>
Cc: Pete Zaitcev <zaitcev@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] RFC: kills consistent_dma_mask
Date: 19 Aug 2003 05:16:47 -0400 [thread overview]
Message-ID: <m3y8xqroqo.fsf@trained-monkey.org> (raw)
In-Reply-To: <m33cfzuen2.fsf@defiant.pm.waw.pl>
>>>>> "Krzysztof" == Krzysztof Halasa <khc@pm.waw.pl> writes:
Krzysztof> 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.
Krzysztof> Possibly. Is that true?
It's not primarily a performance issue it's more of a correctness
issue. You *need* to be able to distinguish the masks between
consistent and dynamic allocations.
Krzysztof> I could imagine even something like that:
Krzysztof> init_module() { using_dac = 1; if (!pci_dma_supported(dev,
Krzysztof> 0xFFFFFFFFFFFFFFFF)) { if (!pci_dma_supported(dev,
Krzysztof> 0xFFFFFFFF)) error; using_dac = 0; } }
Krzysztof> foo = pci_alloc_consistent(pdev, size, &handle,
Krzysztof> 0xFFFFFFFF); bar = pci_map_single(..., using_dac ?
Krzysztof> 0xFFFFFFFFFFFFFFFF : 0xFFFFFFFF);
Krzysztof> I don't think it would be slower. If inlined, if would be
Krzysztof> even faster.
Sure you can add the mask to the allocation calls, but thats going to
cost you since you are not going to be able to make it inline. The
consistent allocations have to be programmed into the IOMMU at mapping
time. Having the consistent DMA mask as we do right now is a lot
cleaner and it means the driver doesn't have to do a ton of runtime
accounting.
>> 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.
Krzysztof> The problem is that the official kernel does NOT contain
Krzysztof> any driver which needs different masks.
Bzzzt, *wrong*! Take a look at drivers/scsi/aic7xxx/aic7xxx_osm_pci.c,
if you look at the code you will notice that the hardware does support
different masks for consistent vs dynamic allocations (32 bit for
consistent vs 39 or 64 bit for dynamic). However make a note that the
driver uses the current interface incorrectly and thinks that
pci_set_dma_mask() actually applies to pci_alloc_consistent, which is
something it never did.
>> > This patch doesn't actually change any current kernel behaviour.
>>
>> Sure it does. It blows all non-mmu ia64 out of the water.
Krzysztof> No. The kernel (2.6.0-test3 at least) doesn't count on that
Krzysztof> under any circumstances.
But it will, as people have been telling you repeatedly, there *is* a
need for this stuff, it's just that not all the patches have been
fully integrated yet. I pushed for this change in 2.5.x so we didn't
have to make infrastructure changes to support this in the middle of
2.6.x.
>> 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.
Krzysztof> Of course this isn't what I'm trying to do.
Well you are trying to remove something people need and which was put
in there after considerable discussion between the involved
parties. The reasonsing was even documented in
Documentation/DMA-mapping.txt.
Jes
next prev parent reply other threads:[~2003-08-19 9:16 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-17 22:34 [PATCH] RFC: kills consistent_dma_mask Krzysztof Halasa
2003-08-18 6:37 ` David S. Miller
2003-08-18 12:44 ` Krzysztof Halasa
2003-08-18 12:43 ` David S. Miller
2003-08-18 15:54 ` Krzysztof Halasa
2003-08-18 16:49 ` David S. Miller
2003-08-18 18:21 ` Krzysztof Halasa
2003-08-18 18:50 ` David S. Miller
2003-08-18 21:58 ` Krzysztof Halasa
2003-08-19 9:24 ` Jes Sorensen
2003-08-19 9:21 ` Jes Sorensen
2003-08-18 13:00 ` Jes Sorensen
2003-08-18 8:07 ` Christoph Hellwig
2003-08-18 15:15 ` Pete Zaitcev
2003-08-18 16:14 ` Krzysztof Halasa
2003-08-19 9:16 ` Jes Sorensen [this message]
2003-08-19 9:49 ` Krzysztof Halasa
2003-08-19 10:15 ` Jes Sorensen
2003-08-19 9:03 ` Jes Sorensen
2003-08-19 13:07 ` Alan Cox
2003-08-19 13:20 ` Jes Sorensen
2003-08-19 16:55 ` David S. Miller
2003-08-19 18:33 ` Alan Cox
2003-08-19 18:31 ` David S. Miller
2003-08-19 20:31 ` Krzysztof Halasa
2003-08-22 11:54 ` Krzysztof Halasa
2003-08-23 17:11 ` Jes Sorensen
2003-08-24 12:06 ` Krzysztof Halasa
2003-08-24 13:00 ` David S. Miller
2003-08-24 19:58 ` Krzysztof Halasa
2003-08-25 8:50 ` Jes Sorensen
2003-08-30 21:18 ` Krzysztof Halasa
2003-08-31 1:50 ` David S. Miller
2003-08-31 12:52 ` Alan Cox
2003-08-31 15:24 ` Krzysztof Halasa
2003-09-01 5:22 ` David S. Miller
2003-09-01 7:34 ` Krzysztof Halasa
2003-09-01 7:43 ` David S. Miller
2003-09-01 17:14 ` Krzysztof Halasa
2003-09-01 17:28 ` David S. Miller
2003-09-01 18:24 ` Krzysztof Halasa
2003-09-01 7:54 ` Alan Cox
2003-09-01 7:52 ` David S. Miller
2003-09-01 16:27 ` Krzysztof Halasa
2003-09-01 17:33 ` David S. Miller
2003-08-25 8:47 ` Jes Sorensen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3y8xqroqo.fsf@trained-monkey.org \
--to=jes@wildopensource.com \
--cc=khc@pm.waw.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox