Message-ID: <CAKv+Gu__yYX-fFqxyxNk3M=Byvw5798po0Jr=qr3anEWKJ+SMA@mail.gmail.com>
Date:   Thu, 8 Mar 2018 15:59:29 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Jeremy Linton <jeremy.linton@....com>
Cc:     Sudeep Holla <sudeep.holla@....com>, linux-acpi@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>, vkilari@...eaurora.org,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        austinwc@...eaurora.org, tnowicki@...iumnetworks.com,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>, dietmar.eggemann@....com,
        Will Deacon <will.deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        morten.rasmussen@....com, Al Stone <ahs3@...hat.com>,
        palmer@...ive.com, Hanjun Guo <hanjun.guo@...aro.org>,
        Catalin Marinas <catalin.marinas@....com>,
        linux-riscv@...ts.infradead.org,
        John Garry <john.garry@...wei.com>, wangxiongfeng2@...wei.com,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Len Brown <lenb@...nel.org>
Subject: Re: [PATCH v7 00/13] Support PPTT for ARM64

On 27 February 2018 at 18:49, Jeremy Linton <jeremy.linton@....com> wrote:
> On 03/01/2018 06:06 AM, Sudeep Holla wrote:
>>
>> Hi Jeremy,
>>
>> On 28/02/18 22:06, Jeremy Linton wrote:
>>>
>>> ACPI 6.2 adds the Processor Properties Topology Table (PPTT), which is
>>> used to describe the processor and cache topology. Ideally it is
>>> used to extend/override information provided by the hardware, but
>>> right now ARM64 is entirely dependent on firmware provided tables.
>>>
>>> This patch parses the table for the cache topology and CPU topology.
>>> When we enable ACPI/PPTT for arm64 we map the physical_id to the
>>> PPTT node flagged as the physical package by the firmware.
>>> This results in topologies that match what the remainder of the
>>> system expects. To avoid inverted scheduler domains we then
>>> set the MC domain equal to the largest cache within the socket
>>> below the NUMA domain.
>>>
>> I remember reviewing and acknowledging most of the cacheinfo stuff with
>> couple of minor suggestions for v6. I don't see any Acked-by tags in
>> this series and don't know if I need to review/ack any more cacheinfo
>> related patches.
>
>
> Hi,
>
> Yes, I didn't put them in because I changed the functionality in 2/13 and
> there is a bug fix in 5/13. I thought you might want to do a quick diff of
> the git v6->v7 tree.
>
> Although given that most of the changes were in response to your comments in
> v6 I probably should have just put the tags in.
>

I get sane output from lstopo when applying these patches and booting
my Socionext SynQuacer in ACPI mode:

$ lstopo-no-graphics
Machine (31GB)
  Package L#0 + L3 L#0 (4096KB)
    L2 L#0 (256KB)
      L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0)
      L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1)
    L2 L#1 (256KB)
      L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2)
      L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3)
    L2 L#2 (256KB)
      L1d L#4 (32KB) + L1i L#4 (32KB) + Core L#4 + PU L#4 (P#4)
      L1d L#5 (32KB) + L1i L#5 (32KB) + Core L#5 + PU L#5 (P#5)
    L2 L#3 (256KB)
      L1d L#6 (32KB) + L1i L#6 (32KB) + Core L#6 + PU L#6 (P#6)
      L1d L#7 (32KB) + L1i L#7 (32KB) + Core L#7 + PU L#7 (P#7)
    L2 L#4 (256KB)
      L1d L#8 (32KB) + L1i L#8 (32KB) + Core L#8 + PU L#8 (P#8)
      L1d L#9 (32KB) + L1i L#9 (32KB) + Core L#9 + PU L#9 (P#9)
    L2 L#5 (256KB)
      L1d L#10 (32KB) + L1i L#10 (32KB) + Core L#10 + PU L#10 (P#10)
      L1d L#11 (32KB) + L1i L#11 (32KB) + Core L#11 + PU L#11 (P#11)
    L2 L#6 (256KB)
      L1d L#12 (32KB) + L1i L#12 (32KB) + Core L#12 + PU L#12 (P#12)
      L1d L#13 (32KB) + L1i L#13 (32KB) + Core L#13 + PU L#13 (P#13)
    L2 L#7 (256KB)
      L1d L#14 (32KB) + L1i L#14 (32KB) + Core L#14 + PU L#14 (P#14)
      L1d L#15 (32KB) + L1i L#15 (32KB) + Core L#15 + PU L#15 (P#15)
    L2 L#8 (256KB)
      L1d L#16 (32KB) + L1i L#16 (32KB) + Core L#16 + PU L#16 (P#16)
      L1d L#17 (32KB) + L1i L#17 (32KB) + Core L#17 + PU L#17 (P#17)
    L2 L#9 (256KB)
      L1d L#18 (32KB) + L1i L#18 (32KB) + Core L#18 + PU L#18 (P#18)
      L1d L#19 (32KB) + L1i L#19 (32KB) + Core L#19 + PU L#19 (P#19)
    L2 L#10 (256KB)
      L1d L#20 (32KB) + L1i L#20 (32KB) + Core L#20 + PU L#20 (P#20)
      L1d L#21 (32KB) + L1i L#21 (32KB) + Core L#21 + PU L#21 (P#21)
    L2 L#11 (256KB)
      L1d L#22 (32KB) + L1i L#22 (32KB) + Core L#22 + PU L#22 (P#22)
      L1d L#23 (32KB) + L1i L#23 (32KB) + Core L#23 + PU L#23 (P#23)
  HostBridge L#0
    PCIBridge
      PCIBridge
        PCI 1b21:0612
          Block(Disk) L#0 "sda"
  HostBridge L#3
    PCI 10de:128b
      GPU L#1 "renderD128"
      GPU L#2 "card0"
      GPU L#3 "controlD64"

So

Tested-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>

*However*, while hacking on the firmware that exposes the table, I
noticed that a malformed structure (incorrect size) can get the parser
in an infinite loop, hanging the boot after

[    8.244281] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[    8.251780] Serial: AMBA driver
[    8.255042] msm_serial: driver initialized
[    8.259752] ACPI PPTT: Cache Setup ACPI cpu 0
[    8.264121] ACPI PPTT: Looking for data cache
[    8.268484] ACPI PPTT: Looking for CPU 0's level 1 cache type 0

so I guess the parsing code could be made a bit more robust?

Powered by blists - more mailing lists