All of lore.kernel.org
 help / color / mirror / Atom feed
From: John David Anglin <dave.anglin@bell.net>
To: Mikulas Patocka <mpatocka@redhat.com>
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 15:13:40 -0400	[thread overview]
Message-ID: <f3f59d8a-3ea4-4a21-8b0d-ba0d63ef1ff6@bell.net> (raw)
In-Reply-To: <fa37987e-568f-9716-719e-85e3da8db47@redhat.com>

On 2024-07-25 1:27 p.m., Mikulas Patocka wrote:
>
> 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.
Our L1_CACHE_BYTES define is wrong.  PA7100 has a L1 length of 16 bytes.
PA7200 to PA7300LC have a length of 32 bytes.  PA8000 to PA8700 have a length of 64
bytes.  PA8800 and PA8900 have a L1 length of 128 bytes (this is from ERS D_Stride).

Thus, L1_CACHE_BYTES should be 128 for CONFIG_PA20 and 32 otherwise.
> 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.
We can continue to define ARCH_DMA_MINALIGN to be L1_CACHE_BYTES.
>
> 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
I believe we need to define ARCH_KMALLOC_MINALIGN.
> 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.

Dave

-- 
John David Anglin  dave.anglin@bell.net


  parent reply	other threads:[~2024-07-25 19:15 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
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 [this message]
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=f3f59d8a-3ea4-4a21-8b0d-ba0d63ef1ff6@bell.net \
    --to=dave.anglin@bell.net \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=dave@parisc-linux.org \
    --cc=deller@gmx.de \
    --cc=linux-parisc@vger.kernel.org \
    --cc=mpatocka@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 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.