mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: "Yang, Shunyong" <shunyong.yang@hxt-semitech.com>,
	Andrew Jones <drjones@redhat.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>,
	Jeremy Linton <jeremy.linton@arm.com>,
	"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
	"will.deacon@arm.com" <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Zheng, Joey" <yu.zheng@hxt-semitech.com>
Subject: Re: [RFC PATCH] arm64: topology: Map PPTT node offset to logic physical package id
Date: Thu, 28 Jun 2018 17:45:23 +0100	[thread overview]
Message-ID: <a3b7e123-7d20-c94c-fe02-64e2b41587d5@arm.com> (raw)
In-Reply-To: <C872769E-A591-4569-9AB9-3EB602D9DCDB@hxt-semitech.com>



On 28/06/18 16:44, Yang, Shunyong wrote:
> Hi, All
>
>> On Jun 28, 2018, at 22:51, Andrew Jones <drjones@redhat.com>
>> wrote:
>>
>>> On Thu, Jun 28, 2018 at 03:09:19PM +0100, Sudeep Holla wrote:
>>>
>>>
>>>> On 28/06/18 14:19, Jeremy Linton wrote: Hi,
>>>>
>>>> On 06/28/2018 07:12 AM, Sudeep Holla wrote:
>>>
>>> [...]
>>>
>>>>>
>>>>> OK sure. I liked the approach in Shunyong's patch. I was
>>>>> thinking if we can avoid the list and dynamic allocation on
>>>>> each addition and make it more simpler.
>>>>>
>>>>
>>>> This one reads simpler, but yes I agree we should try to avoid
>>>> the dynamic allocation.
>>>>
>>>> OTOH, I think that dropping the dynamic allocation leads to an
>>>> algorithm that picks a value and replaces all the matches.
>>>> Which of course is Andrew's patch, although I did have to read
>>>> it a couple times to get a grasp how it works. I'm guessing
>>>> that is due to the fact that he seems to have optimized 3
>>>> double loops into a single loop with two individual nested
>>>> loops. AKA its probably more efficient than the naive
>>>> implementation, but readability seems to have suffered a bit in
>>>> the initial version he posted. I'm not sure the optimization is
>>>> worth it, but I'm guessing there is a middle ground which makes
>>>> it more readable.
>>>>
>>>
>>> Completely agree. RFC from Andrew is not so readable and easy to
>>> understand.
>>
>> Middle ground coming up. At the expense of a triple-nested loop
>> (which will never be N^3 iterations due to conditions at the start
>> of each loop), we can avoid dynamic allocations and list iterations
>> and still gain readability.
>>
>> Thanks, drew
>
> I have a new approach. As we've already got the offset of the node
> with physical package bit set, which is the parent of the cpu we are
> querying. We can iterate from the begining of PPTT to count the nodes
> with physical package bit set till we reach the offset we've got.
> Then, the count value is the package id.

I was thinking of simple solution like add the offset to sorted array
and assign the index to that. In this way if ACPI_PROCESSOR_ID_VALID
flag is set at the package level too and they start and increase
linearly from 0, we are matching them(requires 1 line change I posted in
the other thread)

--
Regards,
Sudeep
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

  reply	other threads:[~2018-06-28 16:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-28  9:18 Shunyong Yang
2018-06-28  9:38 ` Sudeep Holla
2018-06-28 11:57   ` Andrew Jones
2018-06-28 12:12     ` Sudeep Holla
2018-06-28 13:19       ` Jeremy Linton
2018-06-28 14:09         ` Sudeep Holla
2018-06-28 14:51           ` Andrew Jones
2018-06-28 15:44             ` Yang, Shunyong
2018-06-28 16:45               ` Sudeep Holla [this message]
2018-07-12 11:06 ` Will Deacon
2018-07-12 11:20   ` Sudeep Holla

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=a3b7e123-7d20-c94c-fe02-64e2b41587d5@arm.com \
    --to=sudeep.holla@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=drjones@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=shunyong.yang@hxt-semitech.com \
    --cc=will.deacon@arm.com \
    --cc=yu.zheng@hxt-semitech.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

all inboxes | Powered by JetHome®