Linux IOMMU Development
 help / color / mirror / Atom feed
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.

  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