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;
From:   "Yang, Shunyong" <shunyong.yang@hxt-semitech.com>
To:     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
Thread-Topic: [RFC PATCH] arm64: topology: Map PPTT node offset to logic
 physical package id
Thread-Index: AQHUDsGU1koi4KlNakibmAYxryVeeqR04+QAgAAm8wCAAAQNAIAAEsIAgAAN8ICAAAvDgIAAlPT9
Date:   Thu, 28 Jun 2018 15:44:32 +0000
Message-ID: <C872769E-A591-4569-9AB9-3EB602D9DCDB@hxt-semitech.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>
In-Reply-To: <20180628145125.2psdmymtuueiv4xn@kamzik.brq.redhat.com>
Accept-Language: en-US
Content-Language: zh-CN
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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. This avoid list and dynamic allocation. And PPTT provides length for each node, iteration should be easy.
I think this may implemented in pptt.c. 
I am writing this mail on my phone. Maybe I should try to write a patch to test in office tomorrow if you think it's feasible.

Thanks.
Shunyong.