All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Mark Rutland <mark.rutland@arm.com>,
	timur@codeaurora.org, Will Deacon <will.deacon@arm.com>,
	open list <linux-kernel@vger.kernel.org>,
	rrichter@cavium.com, tchalamarla@cavium.com, opendmb@gmail.com
Subject: Re: [PATCH] arm64: Make L1_CACHE_SHIFT configurable
Date: Tue, 13 Feb 2018 11:57:17 +0000	[thread overview]
Message-ID: <20180213115717.4ubsnjraacorwbgk@armageddon.cambridge.arm.com> (raw)
In-Reply-To: <1518479125-14428-1-git-send-email-f.fainelli@gmail.com>

On Mon, Feb 12, 2018 at 03:45:23PM -0800, Florian Fainelli wrote:
> On many platforms, including, but not limited to Brahma-B53 platforms,
> the L1 cache line size is 64bytes. Increasing the value to 128bytes
> appears to be creating performance problems for workloads involving
> network drivers and lots of data movement. In order to keep what was
> introduced with 97303480753e ("arm64: Increase the max granular size"),
> a kernel built for ARCH_THUNDER or ARCH_THUNDER2 will get a 128bytes
> cache line size definition.

This approach has been raised before ([1] as an example but you can
probably find other threads) and NAK'ed. I really don't want this macro
to be configurable as we aim for a single kernel Image.

My proposal was to move L1_CACHE_SHIFT back to 6 and ARCH_DMA_MIN_ALIGN
to 128 as this is the largest known CWG. The networking code is wrong in
assuming SKB_DATA_ALIGN only needs SMP_CACHE_BYTES for DMA alignment but
we can add some safety checks (i.e. WARN_ON) in the arch dma ops code if
the device is non-coherent.

I'll send a patch to the list (hopefully later today).

Catalin

[1] https://patchwork.kernel.org/patch/8634481/

WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Make L1_CACHE_SHIFT configurable
Date: Tue, 13 Feb 2018 11:57:17 +0000	[thread overview]
Message-ID: <20180213115717.4ubsnjraacorwbgk@armageddon.cambridge.arm.com> (raw)
In-Reply-To: <1518479125-14428-1-git-send-email-f.fainelli@gmail.com>

On Mon, Feb 12, 2018 at 03:45:23PM -0800, Florian Fainelli wrote:
> On many platforms, including, but not limited to Brahma-B53 platforms,
> the L1 cache line size is 64bytes. Increasing the value to 128bytes
> appears to be creating performance problems for workloads involving
> network drivers and lots of data movement. In order to keep what was
> introduced with 97303480753e ("arm64: Increase the max granular size"),
> a kernel built for ARCH_THUNDER or ARCH_THUNDER2 will get a 128bytes
> cache line size definition.

This approach has been raised before ([1] as an example but you can
probably find other threads) and NAK'ed. I really don't want this macro
to be configurable as we aim for a single kernel Image.

My proposal was to move L1_CACHE_SHIFT back to 6 and ARCH_DMA_MIN_ALIGN
to 128 as this is the largest known CWG. The networking code is wrong in
assuming SKB_DATA_ALIGN only needs SMP_CACHE_BYTES for DMA alignment but
we can add some safety checks (i.e. WARN_ON) in the arch dma ops code if
the device is non-coherent.

I'll send a patch to the list (hopefully later today).

Catalin

[1] https://patchwork.kernel.org/patch/8634481/

  parent reply	other threads:[~2018-02-13 11:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 23:45 [PATCH] arm64: Make L1_CACHE_SHIFT configurable Florian Fainelli
2018-02-12 23:45 ` Florian Fainelli
2018-02-12 23:52 ` Timur Tabi
2018-02-12 23:52   ` Timur Tabi
2018-02-12 23:57   ` Florian Fainelli
2018-02-12 23:57     ` Florian Fainelli
2018-02-13  0:10     ` Timur Tabi
2018-02-13  0:10       ` Timur Tabi
2018-02-13  0:17       ` Florian Fainelli
2018-02-13  0:17         ` Florian Fainelli
2018-02-19 23:46         ` Jon Masters
2018-02-19 23:46           ` Jon Masters
2018-02-13 11:57 ` Catalin Marinas [this message]
2018-02-13 11:57   ` 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=20180213115717.4ubsnjraacorwbgk@armageddon.cambridge.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=opendmb@gmail.com \
    --cc=rrichter@cavium.com \
    --cc=tchalamarla@cavium.com \
    --cc=timur@codeaurora.org \
    --cc=will.deacon@arm.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.