All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mikulas Patocka <mpatocka@redhat.com>
To: John David Anglin <dave.anglin@bell.net>
Cc: James Bottomley <James.Bottomley@HansenPartnership.com>,
	 John David Anglin <dave@parisc-linux.org>,
	Helge Deller <deller@gmx.de>,
	 linux-parisc@vger.kernel.org
Subject: Re: ARCH_DMA_MINALIGN on PA-RISC
Date: Thu, 25 Jul 2024 19:27:09 +0200 (CEST)	[thread overview]
Message-ID: <fa37987e-568f-9716-719e-85e3da8db47@redhat.com> (raw)
In-Reply-To: <54cb80b8-9c89-4b61-b1cd-1e626daf6719@bell.net>

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]



On Thu, 25 Jul 2024, John David Anglin wrote:

> On 2024-07-24 3:25 p.m., James Bottomley wrote:
> > On Wed, 2024-07-24 at 20:17 +0200, Mikulas Patocka wrote:
> >> Hi
> >>
> >> Thanks for fixing the cache aliasing issues on PA-RISC in the commit
> >> 72d95924ee35c8cd16ef52f912483ee938a34d49.
> >>
> >> I think there is still one problem left - and that is
> >> ARCH_DMA_MINALIGN. Currently, it is 16, which is obviously wrong.
> > I don't think that's obvious, why is it wrong?
> I see this comment in arch/arm64/include/asm/cache.h:
> 
> /*
>  * Memory returned by kmalloc() may be used for DMA, so we must make
>  * sure that all such allocations are cache aligned. Otherwise,
>  * unrelated code may cause parts of the buffer to be read into the
>  * cache before the transfer is done, causing old data to be seen by
>  * the CPU.
>  */
> #define ARCH_DMA_MINALIGN       (128)
> #define ARCH_KMALLOC_MINALIGN   (8)
> 
> L1_CACHE_BYTES is 64 on arm64.
> 
> Possibly, the same can occur on parisc.
> 
> Dave

L1_CACHE_BYTES is a performance hint that is used to avoid cache line 
ping-pong when multiple CPUs modify nearby data.

ARCH_DMA_MINALIGN is the biggest possible cache line size to avoid DMA 
data corruption. As there are some arm64 machines with 128-byte cache 
line, arm64 has to define it to 128.

James said that the L2 cache on PA8800/8900 is coherent with PCI. So, I 
think that ARCH_DMA_MINALIGN should be 64 (is that the L1 cache line size 
on PA8800/8900?).

L1_CACHE_BYTES could be 128 to avoid ping-pong between sockets.

For ARCH_KMALLOC_MINALIGN, there is an arm64 commit 
9382bc44b5f58ccee375f08f518e53c0280051dc, it is an optimization, so that 
they can use cache line size probed at startup instead of 128. I think we 
don't have to do this optimization on PA-RISC, the PA-RISC machines with 
16-byte or 32-byte cache line size are old and slow - so that there is no 
point in trying to optimize kmalloc pools for them.

Mikulas

  reply	other threads:[~2024-07-25 17:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-24 18:17 ARCH_DMA_MINALIGN on PA-RISC Mikulas Patocka
2024-07-24 18:48 ` John David Anglin
2024-07-24 19:25 ` James Bottomley
2024-07-25 16:45   ` John David Anglin
2024-07-25 17:27     ` Mikulas Patocka [this message]
2024-07-25 17:43       ` James Bottomley
2024-07-25 17:46         ` Mikulas Patocka
2024-07-25 19:19           ` James Bottomley
2024-07-25 19:13       ` John David Anglin
2024-07-25 20:05         ` John David Anglin
2024-07-25 20:36           ` Mikulas Patocka
2024-07-25 21:29             ` John David Anglin
2024-07-27 10:24               ` Mikulas Patocka
2024-07-27 15:06                 ` John David Anglin
2024-07-25 17:37   ` Mikulas Patocka

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=fa37987e-568f-9716-719e-85e3da8db47@redhat.com \
    --to=mpatocka@redhat.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dave.anglin@bell.net \
    --cc=dave@parisc-linux.org \
    --cc=deller@gmx.de \
    --cc=linux-parisc@vger.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 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.