linux-kernel - Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1768c791-7456-c1fe-578b-f6245e79746f@codeaurora.org>
Date:   Wed, 7 Feb 2018 18:14:23 +0530
From:   Chintan Pandya <cpandya@...eaurora.org>
To:     Frank Rowand <frowand.list@...il.com>,
        Rob Herring <robh+dt@...nel.org>
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] of: cache phandle nodes to decrease cost of
 of_find_node_by_phandle()



On 2/5/2018 5:53 PM, Chintan Pandya wrote:
> 
>>
>> My question was trying to determine whether the numbers reported above
>> are for a debug configuration or a production configuration.
> My reported numbers are from debug configuration.
> 
>> not a production configuration, I was requesting the numbers for a
>> production configuration.
> I'm working on it. But please expect some delay in my response for this. 
> As I mentioned earlier, I need to work with few teams to get these numbers.
> 
> 
>> show a significant boot time reduction from the patch then there is
>> less justification for adding complexity to the existing code.  I
>> prefer to use simpler data structures and algorithms __if__ extra
>> complexity does not provide any advantage.  The balance between
>> complexity and benefits is a core software engineering issue.
>>
> Ok

Avg Kernel boot time comparison in production set up:

[0] Base: 4519ms
[1] 4115ms (~400ms improvement)
[2] 4115ms (~400ms improvement)
[3] 4177ms (~340ms improvement)

Full data:
[1] 1024 sized pre-populated cache
ITR-1	ITR-2	ITR-3	ITR-4	Avg
4115	4123	4124	4107	4115

[2] Dynamic sized cache allocation/free
ITR-1	ITR-2	ITR-3	ITR-4	Avg
4122	4131	4106	4118	4115

[3] Fixed 64 sized cache
ITR-1	ITR-2	ITR-3	ITR-4	Avg
4153	4186	4198	4181	4177


[1] is my experimental patch and dirty enough to not get merged 
anywhere. So, I will not push it.



Chintan
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project