Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp3903171ybb; Mon, 23 Mar 2020 09:48:21 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsSpvO6+SUMesOv1eXWh1O/EGCMFpH6LG4NnQ160QKvBytLiVr4VOMFky/NbIvYwpCYPx/L X-Received: by 2002:a9d:5e81:: with SMTP id f1mr18030166otl.237.1584982101223; Mon, 23 Mar 2020 09:48:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584982101; cv=none; d=google.com; s=arc-20160816; b=jQC4iM/lpPxZqwCisgop7AZ5j8hB/gY3ELBNZxz9ZsbOZ5mBD+dle6KzcDhkxCTSIn ijO3TEPOQTX3P2oNVF+A6MysyI+Eyi/cBnP9L37uXuJJpG3fBPMvhXh4o2c3nTwifbo+ 0oePZLrHOOd8elBylgsc1p9+ntvyv46uDGGdttAvI650HQr3yb5cBgxG396GVBK5L9us a7+ysgJeeuFNpKWj2l5NGEviZ95gQJb+3X460vQRem2511B7VxhPUGgVIPLZRTcJjfE3 sOUoqrnGoFp3pMVq8x8kzKAcWIgmYZtBbOniAOavi33aQTcj01JL7NBOetC/jZvY4lRT HNlQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=S0wzAbQADit2y8fm4GttbH+N8ekuj5N7NHRN87kDDh0=; b=xzSOognWSiZ4Z7fKAT+yC7lT4MgAUMT+x4PVenWe0IgYywB76M3PyWx0CRZtihO6Dl Xv/0jJzEH2Ftd6eO13hg0Azfa45VsI1wcw/t1CNCZFN4Usmq0nV+4kQq2pLKf3MPK+2t gYDcTnLA8JCMtTGcEr9aBDa+FWPmo6I4TOtezgkdrcCbMA+itpUZQ83FjO433sTXBTb2 HSRGAkEA049+ysPVpl9Bq0acPzm+ufKuj99WQo5IVZhj6oa1ff39le724rv8tNpFm1xf R5ag1pt/9J4fNsMjwKPFc3hdF3vizKypbICnctV9g5OJap7gFPfr2EPLSBuxabRSehgF Ki4w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b9si10521872ots.148.2020.03.23.09.48.04; Mon, 23 Mar 2020 09:48:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727611AbgCWQra (ORCPT + 99 others); Mon, 23 Mar 2020 12:47:30 -0400 Received: from foss.arm.com ([217.140.110.172]:51886 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727556AbgCWQra (ORCPT ); Mon, 23 Mar 2020 12:47:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 274921FB; Mon, 23 Mar 2020 09:47:30 -0700 (PDT) Received: from lakrids.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 91D423F7C3; Mon, 23 Mar 2020 09:47:29 -0700 (PDT) Date: Mon, 23 Mar 2020 16:47:24 +0000 From: Mark Rutland To: Changbin Du Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: Two questions about cache coherency on arm platforms Message-ID: <20200323164723.GA8652@lakrids.cambridge.arm.com> References: <20200323123524.w67fici6oxzdo665@mail.google.com> <20200323131720.GE2597@C02TD0UTHF1T.local> <20200323161537.ptjrihqotgmon7tr@mail.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200323161537.ptjrihqotgmon7tr@mail.google.com> User-Agent: Mutt/1.11.1+11 (2f07cb52) (2018-12-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.