From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4001:c06::243; helo=mail-io0-x243.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4C6CB22402DEB for ; Thu, 8 Mar 2018 12:31:45 -0800 (PST) Received: by mail-io0-x243.google.com with SMTP id v6so1122326iog.7 for ; Thu, 08 Mar 2018 12:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HC4mYkOyxOQsKxDd3vdSMdeYRh+W9G8ku7N279hQR/U=; b=UwxThnPz46k22XekYF+sXN0A+6ogQnqsAuHXZufrOWujyHHchJjGYfY+pdCE/M/AkJ IBpgkat0uSlAV6V67bT5tCq8vQFFbLrnQKUO2Pj20YtN7nngEzk6pcLCdwEdQgqoP2Fu 8GoxOaglcWdpEtmEkLorHjrmm3Gh3cwjwIAXE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HC4mYkOyxOQsKxDd3vdSMdeYRh+W9G8ku7N279hQR/U=; b=IsR6TzfFkm+RkHlWF//TTO2bM7Tiwzrmg0X7dYDzWCI2GZbGDUoqDiCJ6AxHZBprm0 SIdlgWxT9AhTJ3Jh9eqZDaRWQ+OmbBlsR6lde4f2Wt/BjLTLpvC1WKVRVvt8x2Ob/Prk JW3fr6LpsbOgZBmkd2Q9revwf+ZiX63/zQxOSJ+ATePT2710jhr61jOQcvvPV4wq1bsw vlvFOpTCXHkeGmbqtu9zZ2spAP8YsE2X6kHeZIkO3e2Bjy1eImYJBVxgtKOGmJOROBZk tCRpSLvsNzCYT7ZvYCHcMcEkrw8NpC9nj7ovsB80IeGSZDp4fsVLqkbO1mjiSA0FKKja Yu/g== X-Gm-Message-State: AElRT7ElB1E0Oi+ECfrYpCeJCKvXpQDJ8yMcuu+JRfbClOHr+nY45yD1 XZ/JDB9Z+NL4JfRqp1NsCtxKkZ5pZQ55CDAut93fmg== X-Google-Smtp-Source: AG47ELskXU2Lbqcdso3r6OF84fH0RQGKkqzvNcxxpoqk1JCHf2IKS966YP7lkdM9cCFGvaMIzhOZAPPBpM2pVXPgqX0= X-Received: by 10.107.213.72 with SMTP id x8mr29027923ioc.60.1520541481066; Thu, 08 Mar 2018 12:38:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 8 Mar 2018 12:38:00 -0800 (PST) In-Reply-To: References: <20180308131353.17389-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 8 Mar 2018 20:38:00 +0000 Message-ID: To: Jeremy Linton Cc: "edk2-devel@lists.01.org" , Leif Lindholm , Graeme Gregory Subject: Re: [PATCH edk2-platforms] Silicon/SynQuacer: add PPTT ACPI table to describe cache topology X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2018 20:31:45 -0000 Content-Type: text/plain; charset="UTF-8" On 8 March 2018 at 17:59, Ard Biesheuvel wrote: > On 8 March 2018 at 17:50, Jeremy Linton wrote: >> Hi, >> >> >> On 03/08/2018 11:27 AM, Ard Biesheuvel wrote: >>> >>> On 8 March 2018 at 17:24, Jeremy Linton wrote: >>>> >>>> Hi, >>>> >>>> >>>> On 03/08/2018 07:13 AM, Ard Biesheuvel wrote: >>>>> >>>>> >>>>> Add a ACPI Processor Properties Topology Table (PPTT) to the SynQuacer >>>>> builds. This information is used by the OS to tune the scheduler. >>>>> >>>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>>> Signed-off-by: Ard Biesheuvel >>>>> --- >>>>> This produces the following topology after applying Jeremy's patches: >>>>> >>>>> $ 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" >>>>> >>>>> Silicon/Socionext/SynQuacer/AcpiTables/AcpiTables.inf | 1 + >>>>> Silicon/Socionext/SynQuacer/AcpiTables/Pptt.aslc | 221 >>>>> ++++++++++++++++++++ >>>> >>>> >>>> >>>> So, the above looks good. OTOH, this is yet another manually >>>> created/hard-coded ACPI table, subject to change every-time another SOC >>>> is >>>> released. I have a couple similar ones, but haven't post them because I >>>> believe the HiSi folks have done us a favor and created a table generator >>>> which does 90% of this work by probing the hardware, and creating a >>>> "compressed" representation of the table. Leaving the individual >>>> platforms >>>> to only fill out LLCs and such which can't be probed. >>>> >>>> It would be great if the remaining HiSi bits were removed and the whole >>>> thing made generic enough to plug in to these individual platforms, so >>>> that >>>> they only need supply their nonstandard bits and the rest is taken care >>>> of. >>>> >>> >>> Yeah, I am aware of that. But to be honest, for a platform such as >>> this one, where the information is 100% static, I'd much rather have a >>> single .c file like this that never changes once you check it in. >>> >> >> Maybe, but even if there is never an identical machine with a few cores >> extra (or removed), you have to deal with the possibility that the standard >> is going to be updated (say to add a leaf node flag). If/when that happens >> you now have the technical debt of having to go manually touch the tables vs >> updating the generator code and being done with it across all the platforms. >> Particularly since other people are just going to take the same shortcut >> next time of just copy-pasting this table and tweaking it, rather than >> trying to create a library out of the HiSi code. > > I agree up to a point, and I think we are conflating two different > things here. I am all for abstracting PPTT table generation, but only > if it doesn't move processing of information known at compile time to > runtime. BTW the architecture does not permit inferring cache geometry from the CCSIDR field: """ The parameters NumSets, Associativity, and LineSize in these registers define the architecturally visible parameters that are required for the cache maintenance by Set/Way instructions. They are not guaranteed to represent the actual microarchitectural features of a design. You cannot make any inference about the actual sizes of caches based on these parameters. """ and we know that there are cores that describe their caches as having a single set and a single way, because they don't implement maintenance by set/way at all and can only be cleaned or invalidated wholesale.