Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
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
To:     "Yang, Shunyong" <shunyong.yang@hxt-semitech.com>,
        Andrew Jones <drjones@redhat.com>
References: <1530177508-15298-1-git-send-email-shunyong.yang@hxt-semitech.com>
 <cb057c6a-0eb4-581e-c259-7a31545e0ae7@arm.com>
 <20180628115748.kprobde6c3joc6ll@kamzik.brq.redhat.com>
 <f9376e47-e2ae-b2f4-db23-07698364f1bb@arm.com>
 <b9b537e7-8f7b-07cc-a99d-bcaa8f5d60d5@arm.com>
 <e5b44e41-6d5b-2587-2628-3bcfbee4e00b@arm.com>
 <20180628145125.2psdmymtuueiv4xn@kamzik.brq.redhat.com>
 <C872769E-A591-4569-9AB9-3EB602D9DCDB@hxt-semitech.com>
From:   Sudeep Holla <sudeep.holla@arm.com>
Organization: ARM
Message-ID: <a3b7e123-7d20-c94c-fe02-64e2b41587d5@arm.com>
Date:   Thu, 28 Jun 2018 17:45:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <C872769E-A591-4569-9AB9-3EB602D9DCDB@hxt-semitech.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Received-SPF: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2018 16:45:25.5240
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a2dfc4d6-1e03-4a11-fae4-08d5dd168cac
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR08MB2764
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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 confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease 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.