linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeremy Linton <jeremy.linton@arm.com>
To: John Garry <john.garry@huawei.com>, linux-arm-kernel@lists.infradead.org
Cc: linux-acpi@vger.kernel.org, catalin.marinas@arm.com,
	will.deacon@arm.com, rjw@rjwysocki.net, lenb@kernel.org,
	sudeep.holla@arm.com, Linuxarm <linuxarm@huawei.com>,
	"Guohanjun (Hanjun Guo)" <guohanjun@huawei.com>,
	wanghuiqiang <wanghuiqiang@huawei.com>,
	yaohongbo@huawei.com
Subject: Re: [PATCH 2/2] arm64: topology: Use PPTT to determine if PE is a thread
Date: Fri, 7 Jun 2019 14:21:34 -0500	[thread overview]
Message-ID: <24541261-f86d-0d19-6275-6e110144e761@arm.com> (raw)
In-Reply-To: <be03d428-b543-0233-a98b-233f367a6bd0@huawei.com>

Hi,

Thanks for testing and looking at this.

On 6/6/19 3:49 AM, John Garry wrote:
> On 23/05/2019 23:40, Jeremy Linton wrote:
>> ACPI 6.3 adds a thread flag to represent if a CPU/PE is
>> actually a thread. Given that the MPIDR_MT bit may not
>> represent this information consistently on homogeneous machines
>> we should prefer the PPTT flag if its available.
>>
> 
> Hi Jeremy,
> 
> I was just wondering if we should look to get this support backported 
> (when merged)?

I imagine that will happen..

> 
> I worry about the case of a system with the CPU having MT bit in the 
> MPIDR (while not actually threaded), i.e. the system for which these 
> PPTT flags were added (as I understand).

I have tested this patch on DAWN which happens to have the MT bit set, 
but isn't threaded, and it appears to work.

> 
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>>  arch/arm64/kernel/topology.c | 8 +++++---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
>> index 0825c4a856e3..cbbedb53cf06 100644
>> --- a/arch/arm64/kernel/topology.c
>> +++ b/arch/arm64/kernel/topology.c
>> @@ -346,11 +346,9 @@ void remove_cpu_topology(unsigned int cpu)
>>   */
>>  static int __init parse_acpi_topology(void)
>>  {
>> -    bool is_threaded;
>> +    int is_threaded;
>>      int cpu, topology_id;
>>
>> -    is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
>> -
>>      for_each_possible_cpu(cpu) {
>>          int i, cache_id;
>>
>> @@ -358,6 +356,10 @@ static int __init parse_acpi_topology(void)
>>          if (topology_id < 0)
>>              return topology_id;
>>
>> +        is_threaded = acpi_pptt_cpu_is_thread(cpu);
>> +        if (is_threaded < 0)
>> +            is_threaded = read_cpuid_mpidr() & MPIDR_MT_BITMASK;
>> +
>>          if (is_threaded) {
>>              cpu_topology[cpu].thread_id = topology_id;
> 
> For described above scenario, this seems wrong.

I'm not sure I understand the concern.

This is going to ignore the MPIDR_MT bit on any machine with a PPTT 
revision > 1. Are you worried about the topology_id assignment?


> 
>>              topology_id = find_acpi_cpu_topology(cpu, 1);
>>
> 
> BTW, we did test an old kernel with 6.3 PPTT bios for this on D06 (some 
> versions have MT bit set), and it looked ok. But I am still a bit 
> skeptical.
> 
> Thanks,
> John
> 
> 


Thanks,

  reply	other threads:[~2019-06-07 19:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 22:40 [PATCH 0/2] arm64/PPTT ACPI 6.3 thread flag support Jeremy Linton
2019-05-23 22:40 ` [PATCH 1/2] ACPI/PPTT: Add support for ACPI 6.3 thread flag Jeremy Linton
2019-06-07 10:03   ` Sudeep Holla
2019-05-23 22:40 ` [PATCH 2/2] arm64: topology: Use PPTT to determine if PE is a thread Jeremy Linton
2019-06-06  8:49   ` John Garry
2019-06-07 19:21     ` Jeremy Linton [this message]
2019-06-10  8:30       ` John Garry
2019-06-11 19:02         ` Jeremy Linton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=24541261-f86d-0d19-6275-6e110144e761@arm.com \
    --to=jeremy.linton@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=john.garry@huawei.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linuxarm@huawei.com \
    --cc=rjw@rjwysocki.net \
    --cc=sudeep.holla@arm.com \
    --cc=wanghuiqiang@huawei.com \
    --cc=will.deacon@arm.com \
    --cc=yaohongbo@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).