All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Yang Shi <yang@os.amperecomputing.com>,
	Baruch Siach <baruch@tkos.co.il>,
	will@kernel.org, ptesarik@suse.com, hch@lst.de,
	jiangyutang@os.amperecomputing.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64: mm: fix zone_dma_limit calculation
Date: Fri, 29 Nov 2024 19:38:25 +0000	[thread overview]
Message-ID: <Z0oYMXMGYgXoyon7@arm.com> (raw)
In-Reply-To: <7720d275-bc52-49c3-949a-6a6a32157418@arm.com>

On Fri, Nov 29, 2024 at 06:06:50PM +0000, Robin Murphy wrote:
> On 2024-11-27 5:49 pm, Catalin Marinas wrote:
> > If IORT or DT indicate a large mask covering the whole RAM (i.e. no
> > restrictions), in an ideal world, we should normally extend ZONE_DMA to
> > the same.
> 
> That's not right, ZONE_DMA should still be relatively limited in size
> (unless we really do only have a tiny amount of RAM) - just because a DT
> dma-ranges property says the system interconnect can carry >32 address bits
> in general doesn't mean that individual device DMA masks can't still be
> 32-bit or smaller. IIRC we're still implicitly assuming that if DT does
> describe an offset range into "high" RAM, it must represent a suitable
> lowest common denominator for all relevant devices already, and therefore we
> can get away with sizing ZONE_DMA off it blindly.

Fine by me to keep ZONE_DMA in the low range always. I was thinking of
only doing this if ZONE_DMA32 is enabled.

> After staring at it for long enough, I think $SUBJECT patch is actually
> correct as it is.

Thanks Robin for having a look. Can I add your reviewed-by?

> In fact I'm now wondering why the fix was put inside
> max_zone_phys() in the first place, since it's clearly pointless to clamp
> DMA_BIT_MASK(32) to U32_MAX in the dma32_phys_limit case...

I came to the same conclusion. I think it might have been some left-over
from when we had a ZONE_DMA32 in the above 4GB (AMD Seattle?). Than we
changed it a few times but only focused on this function for setting the
limits.

> However the commit message is perhaps not as clear as it could be -
> technically we are correctly *calculating* the appropriate effective
> zone_dma_limt value within the scope of zone_sizes_init(), we're just
> failing to properly update the actual zone_dma_limit variable for the
> benefit of other users.

I'll have a look next week at rewriting the commit message, unless Yang
does it first. I'm planning to queue this patch for -rc2.

-- 
Catalin


  reply	other threads:[~2024-11-29 19:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-25 17:16 [PATCH] arm64: mm: fix zone_dma_limit calculation Yang Shi
2024-11-26  6:27 ` Baruch Siach
2024-11-26 17:38   ` Yang Shi
2024-11-27 17:49     ` Catalin Marinas
2024-11-29 18:06       ` Robin Murphy
2024-11-29 19:38         ` Catalin Marinas [this message]
2024-12-02 16:41           ` Yang Shi
2024-12-03 21:20 ` Catalin Marinas

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=Z0oYMXMGYgXoyon7@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=baruch@tkos.co.il \
    --cc=hch@lst.de \
    --cc=jiangyutang@os.amperecomputing.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ptesarik@suse.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    --cc=yang@os.amperecomputing.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.