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;
Subject: Re: [PATCH v7 13/13] arm64: topology: divorce MC scheduling domain
 from core_siblings
To:     Morten Rasmussen <morten.rasmussen@arm.com>,
        Jeremy Linton <jeremy.linton@arm.com>
Cc:     mark.rutland@arm.com, vkilari@codeaurora.org,
        lorenzo.pieralisi@arm.com, catalin.marinas@arm.com,
        tnowicki@caviumnetworks.com, gregkh@linuxfoundation.org,
        will.deacon@arm.com, dietmar.eggemann@arm.com, rjw@rjwysocki.net,
        linux-kernel@vger.kernel.org, ahs3@redhat.com,
        linux-acpi@vger.kernel.org, palmer@sifive.com,
        hanjun.guo@linaro.org, sudeep.holla@arm.com,
        austinwc@codeaurora.org, linux-riscv@lists.infradead.org,
        john.garry@huawei.com, wangxiongfeng2@huawei.com,
        linux-arm-kernel@lists.infradead.org, lenb@kernel.org
References: <20180228220619.6992-1-jeremy.linton@arm.com>
 <20180228220619.6992-14-jeremy.linton@arm.com>
 <20180301155216.GI4589@e105550-lin.cambridge.arm.com>
 <5d6bf4cf-2f6d-d123-f17f-d47d8e74c16c@arm.com>
 <20180306160721.GJ4589@e105550-lin.cambridge.arm.com>
 <8ac3567c-9fd8-4b0c-121c-287a027b5156@arm.com>
 <20180307130623.GK4589@e105550-lin.cambridge.arm.com>
From:   Brice Goglin <brice.goglin@gmail.com>
Message-ID: <d6497158-c58f-4fd4-4613-699fb2af7a61@gmail.com>
Date:   Thu, 8 Mar 2018 21:41:17 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180307130623.GK4589@e105550-lin.cambridge.arm.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> Is there a good reason for diverging instead of adjusting the
> core_sibling mask? On x86 the core_siblings mask is defined by the last
> level cache span so they don't have this issue. 

No. core_siblings is defined as the list of cores that have the same
physical_package_id (see the doc of sysfs topology files), and LLC can
be smaller than that.
Example with E5v3 with cluster-on-die (two L3 per package, core_siblings
is twice larger than L3 cpumap):
https://www.open-mpi.org/projects/hwloc/lstopo/images/2XeonE5v3.v1.11.png
On AMD EPYC, you even have up to 8 LLC per package.

Brice