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] [day] [month] [year] [list]

Message-ID: <2e95e5f3-0f50-fb06-354e-918b48a55732@gmail.com>
Date:   Wed, 7 Feb 2018 12:09:26 -0800
From:   Frank Rowand <frowand.list@...il.com>
To:     Chintan Pandya <cpandya@...eaurora.org>,
        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 02/07/18 04:44, Chintan Pandya wrote:
> 
> 
> 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

Thank you very much.  This looks like a real improvement to me.

I'll rebase my patches, updated to address the comments, on 4.16-rc1.

-Frank