public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Changbin Du <changbin.du@gmail.com>
Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org
Subject: Re: Two questions about cache coherency on arm platforms
Date: Mon, 23 Mar 2020 16:47:24 +0000	[thread overview]
Message-ID: <20200323164723.GA8652@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20200323161537.ptjrihqotgmon7tr@mail.google.com>

On Mon, Mar 23, 2020 at 04:15:40PM +0000, Changbin Du wrote:
> Hi Mark,
> Thanks for your answer. I still don't understand the first question.
> 
> On Mon, Mar 23, 2020 at 01:17:20PM +0000, Mark Rutland wrote:
> > On Mon, Mar 23, 2020 at 08:35:26PM +0800, Changbin Du wrote:
> > > Hi, All,
> > > I am not very familiar with ARM processors. I have two questions about
> > > cache coherency. Could anyone help me?
> > > 
> > > 1. How is cache coherency maintenanced on ARMv8 big.LITTLE system?
> > > As far as I know, big cores and little cores are in seperate clusters on
> > > big.LITTLE system.
> > 
> > This is often true, but not always the case. For example, with DSU big
> > and little cores can be placed within the same cluster.
> 
> Yes, it is ture for DynamIQ that bl cores can be placed within the same cluster.
> But I don't understand how linux support big.LITTLE before DynamIQ.

Multiple clusters can be in the same Inner Shareable domain, and Linux
relies on this being the case for systems it supports. It's possible to
build a system where clusters are in distinct Inner Shareable domains,
but Linux does not support using all cores on such a system.

Even with CCI, CCN, CMN, etc, Linux requires that all cores (which it is
told about) are in the same Inner Shareable domain. That is what is
commonly built.

> I read below description in ARM Cortex-A Series Programmer’s Guide for
> ARMv8-A.
>  | big.LITTLE software models require transparent and efficient transfer of data between big and LITTLE clusters.
>  | Coherency between clusters is provided by a cache-coherent interconnect such as the ARM CoreLink CCI-400 described in Chapter 14.
> 
> So I think  big cores and little cores are in different clusters in this
> case. Then we are not within the same Inner Shareable domain?

Linux requires that those clusters are in the same Inner Shareable
domain, and that's what people (mostly) build today.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-03-23 16:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-23 12:35 Two questions about cache coherency on arm platforms Changbin Du
2020-03-23 13:17 ` Mark Rutland
2020-03-23 16:15   ` Changbin Du
2020-03-23 16:47     ` Mark Rutland [this message]
2020-03-24  0:02       ` Changbin Du

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=20200323164723.GA8652@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=changbin.du@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox