[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e4f9e8f1-c200-7350-79af-7f3e9e5c3106@semihalf.com>
Date: Fri, 27 Oct 2017 07:21:13 +0200
From: Tomasz Nowicki <tn@...ihalf.com>
To: John Garry <john.garry@...wei.com>,
Tomasz Nowicki <tnowicki@...iumnetworks.com>,
Jeremy Linton <jeremy.linton@....com>,
linux-acpi@...r.kernel.org
Cc: mark.rutland@....com, Jonathan.Zhang@...ium.com,
Jayachandran.Nair@...ium.com, lorenzo.pieralisi@....com,
austinwc@...eaurora.org, linux-pm@...r.kernel.org,
jhugo@...eaurora.org, gregkh@...uxfoundation.org,
sudeep.holla@....com, rjw@...ysocki.net,
linux-kernel@...r.kernel.org, will.deacon@....com,
wangxiongfeng2@...wei.com, viresh.kumar@...aro.org,
hanjun.guo@...aro.org, catalin.marinas@....com, ahs3@...hat.com,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 1/7] ACPI/PPTT: Add Processor Properties Topology Table
parsing
Hi John,
On 19.10.2017 12:25, John Garry wrote:
> On 19/10/2017 06:18, Tomasz Nowicki wrote:
>>>
>>> Summary:
>>>
>>> I'm not at all happy with this specification's attempt to leave out
>>> pieces of information which make parsing things more deterministic. In
>>> this case I'm happy to demote the message level, but not remove it
>>> entirely but I do think the obvious case you list shouldn't be the
>>> default one.
>>>
>>> Lastly:
>>>
>>> I'm assuming the final result is that the table is actually being
>>> parsed correctly despite the ugly message?
>>
>> Indeed, the ThunderX2 PPTT table is being parsed so that topology shown
>> in lstopo and lscpu is correct.
>
> Hi Tomasz,
>
> Can you share the lscpu output? Does it have cluster info? I did not
> think that lscpu has a concept of clustering.
>
> I would say that the per-cpu cluster index sysfs entry needs be added to
> drivers/base/arch_topology.c (and other appropiate code under
> GENERIC_ARCH_TOPOLOGY) to support this.
Here is what I get:
tn@...2-11 [~]$ lscpu -ap
# The following is the parsable format, which can be fed to other
# programs. Each different item in every column has an unique ID
# starting from zero.
# CPU,Core,Socket,Node,,L1d,L1i,L2,L3
[...]
1,0,0,0,,0,0,0,0
[...]
so yes, no cluster info.
Thanks,
Tomasz
Powered by blists - more mailing lists