[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH 0/2] Boot time cpupools


  • To: Julien Grall <julien@xxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Tue, 23 Nov 2021 14:45:16 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KDPhrhNp8c4RyScvZPAQiS28zsf54b2antgvUA/wqDY=; b=YuW90gdT5QAKd2JXHIJENpa4pKSThTtsuUNur06TqaDoQ9e0nkTDbeObnbN07qPxRTDmQQBFa46297NP2+ZBdWqTjiS+okwSRMl8EADiY8BPNo0fM2Plq2jbkIATA30Uwtf363idJSY0M99FMeMf/gL9fUgPO90E6I5yDnw2w6QQ1zqmVApJ/TK7Nm9V6u3QEqEoWJWj/q2RzpYtYhC761y7GaRb2zfMvtvz9AWE04a4JsyW7nltq5lrCIeaZt8yY2PXGbT9cmRyJR+wAKaSJoBUmolCs2D2fDvDRELsdmSNfAbc0UStP4vxvhNBLXBLErQ0fARnujWXyxnSwrD9YQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GqF79gkG+P/2bMMq81uOoODLscnDrmgjCmXXXbqyaaOrvvJ8SqiVTls+3CZWMiUYjVWFA5/Z7SJNeyrze7qAcIlzhaIC+rrtCArX/BkQJ5ZA8hGKzWbgHogyzxwMuVMpZaxX2p5eN/LYolHMQ0BGWKyOkfJLWZG/243rum+JjfJO2AGek6hofpW5HmX2g+4OlNjUgERhnu3ALHHIq+URrDDTzHAR7aEOkufaBef2nNigB361kRkBT90Jk8DVworanPJqlQ4tyrdKJcPbUUjLJ0XU+pLd1uuU5vUc86/RupldyJyuWHSAWbVIhrR6ePagKIHiYtLyvrYBcG3Aoto0Zg==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>, Luca Fancellu <Luca.Fancellu@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>
  • Delivery-date: Tue, 23 Nov 2021 14:45:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHX25mOHH0z58pAdkqC6AziO7R1GqwHg+AAgAAN94CAAAkVgIAABTgAgAB2SICAAHfeAIACmeEAgAAOqoCABfUlAIAADkaA
  • Thread-topic: [RFC PATCH 0/2] Boot time cpupools

Hi Julien,

> On 23 Nov 2021, at 13:54, Julien Grall <julien@xxxxxxx> wrote:
> 
> Hi Stefano,
> 
> On 19/11/2021 18:55, Stefano Stabellini wrote:
>> On Fri, 19 Nov 2021, Julien Grall wrote:
>>> I like better Juergen's version. But before agreeing on the command line , I
>>> would like to understand how Linux is dealing with big.LITTLE today (see my
>>> question above).
>> I also like Juergen's version better :-)
>> The device tree binding that covers big.LITTLE is the same that covers
>> cpus: Documentation/devicetree/bindings/arm/cpus.yaml
> 
> Are you sure? I found Documentation/devicetree/bindings/arm/cpu-capacity.txt.
> 
>> So basically, you can tell it is a big.LITTLE system because the
>> compatible strings differ between certain cpus, e.g.:
>>       cpu@0 {
>>         device_type = "cpu";
>>         compatible = "arm,cortex-a15";
>>         reg = <0x0>;
>>       };
>>       cpu@1 {
>>         device_type = "cpu";
>>         compatible = "arm,cortex-a15";
>>         reg = <0x1>;
>>       };
>>       cpu@100 {
>>         device_type = "cpu";
>>         compatible = "arm,cortex-a7";
>>         reg = <0x100>;
>>       };
>>       cpu@101 {
>>         device_type = "cpu";
>>         compatible = "arm,cortex-a7";
>>         reg = <0x101>;
>>       };
> 
> I have not found any code in Linux using the compatible. Instead, they all 
> seem to use the cpu-map (see drivers/base/arch_topology.c).
> 
> Anyway, to me it would be better to parse the Device-Tree over using the 
> MIDR. The advantage is we can cover a wide range of cases (you may have 
> processor with the same MIDR but different frequency). For now, we could 
> create a cpupool per cluster.

This is a really good idea as this could also work for NUMA systems.

So reg & ~0xff would give the cluster number ?

We will probably end up splitting cores into different cpupools even if they 
are all the same as there are several CPUs having several clusters but the same 
cores (I recall some NXP boards being like that).

Some device tree also have a cpu-map definition:
        cpu-map {
            cluster0 {
                core0 {
                    cpu = <&A57_0>;
                };
                core1 {
                    cpu = <&A57_1>;
                };
            };

            cluster1 {
                core0 {
                    cpu = <&A53_0>;
                };
                core1 {
                    cpu = <&A53_1>;
                };
                core2 {
                    cpu = <&A53_2>;
                };
                core3 {
                    cpu = <&A53_3>;
                };
            };
        };

@stefano: is the cpu-map something standard ? Lots of device trees do have it 
in Linux now but I do not recall seeing that on older device trees.

Maybe using cpu-map could be a solution, we could say that device tree without 
a cpu-map are not supported.

Cheers
Bertrand



> 
> Cheers,
> 
> -- 
> Julien Grall




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.