From: Robin Murphy <robin.murphy@arm.com>
To: Joerg Roedel <joro@8bytes.org>
Cc: will@kernel.org, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Jakub Kicinski <kuba@kernel.org>,
John Garry <john.g.garry@oracle.com>
Subject: Re: [PATCH v4] iommu: Optimise PCI SAC address trick
Date: Wed, 24 May 2023 15:56:57 +0100 [thread overview]
Message-ID: <b940e9f5-5770-73a4-d139-06af82fb482f@arm.com> (raw)
In-Reply-To: <ZGzkf68s_0H-jFS7@8bytes.org>
On 23/05/2023 5:06 pm, Joerg Roedel wrote:
> On Fri, Apr 14, 2023 at 06:45:57PM +0100, Robin Murphy wrote:
>> Sounds good - I'm considerably more confident in this approach, but although
>> it should not be able to break any scenario which wasn't already broken, it
>> could potentially still make such a breakage more noticeable. Thus in all
>> honesty I'd feel happiest giving it a full cycle of -next coverage as well.
>
> I had some second thoughts on this, wouldn't it be better to change the
> allocator to allocate from lowest addresses first? Then we can just
> remove the SAC trick and rely on dma-masks only.
>
> Thoughts?
Yes, in the long term I definitely would like to have a more flexible
allocator - this is more of a stop-gap measure that's an easy win with
what we have now.
Top-down allocation is nice in that it makes for easily recognisable DMA
addresses, and does do a great job of flushing out bugs, but having the
option of bottom-up allocation would definitely be useful in various
cases - realistically it's pretty much a prerequisite for converting
arch/arm to use iommu-dma. However, given all the other scalability
issues that keep coming to light, I think that's going to be the tipping
point for ripping up the existing code and giving it a major overhaul,
which I would love to be able to get stuck in to, but don't have the
capacity for at the moment.
Thanks,
Robin.
next prev parent reply other threads:[~2023-05-24 14:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-13 13:40 [PATCH v4] iommu: Optimise PCI SAC address trick Robin Murphy
2023-04-13 14:02 ` Jakub Kicinski
2023-04-14 11:45 ` Joerg Roedel
2023-04-14 17:45 ` Robin Murphy
2023-05-23 16:06 ` Joerg Roedel
2023-05-24 14:56 ` Robin Murphy [this message]
2023-06-13 17:58 ` Jakub Kicinski
2023-06-15 7:49 ` John Garry
2023-06-15 9:04 ` Robin Murphy
2023-06-15 10:11 ` John Garry
2023-06-15 11:41 ` Robin Murphy
2023-06-15 12:15 ` John Garry
2023-04-18 9:23 ` Vasant Hegde
2023-04-18 10:19 ` John Garry
2023-04-18 17:36 ` Linus Torvalds
2023-04-18 18:50 ` John Garry
2023-04-18 10:57 ` Robin Murphy
2023-04-18 13:05 ` Vasant Hegde
2023-07-14 14:09 ` Joerg Roedel
2023-07-17 9:24 ` John Garry
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=b940e9f5-5770-73a4-d139-06af82fb482f@arm.com \
--to=robin.murphy@arm.com \
--cc=iommu@lists.linux.dev \
--cc=john.g.garry@oracle.com \
--cc=joro@8bytes.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=will@kernel.org \
/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