linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frank Rowand <frowand.list@gmail.com>
To: Rob Herring <robh@kernel.org>
Cc: cpandya@codeaurora.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
Date: Fri, 9 Mar 2018 17:20:50 -0800	[thread overview]
Message-ID: <c2e23a6f-efb5-6476-4434-6f82c924c373@gmail.com> (raw)
In-Reply-To: <20180309230346.7mphnvsdxugpmtmc@rob-hp-laptop>

On 03/09/18 15:03, Rob Herring wrote:
> On Sun, Mar 04, 2018 at 04:14:47PM -0800, frowand.list@gmail.com wrote:
>> From: Frank Rowand <frank.rowand@sony.com>
>>
>> Create a cache of the nodes that contain a phandle property.  Use this
>> cache to find the node for a given phandle value instead of scanning
>> the devicetree to find the node.  If the phandle value is not found
>> in the cache, of_find_node_by_phandle() will fall back to the tree
>> scan algorithm.
>>
>> The cache is initialized in of_core_init().
>>
>> The cache is freed via a late_initcall_sync() if modules are not
>> enabled.
>>
>> If the devicetree is created by the dtc compiler, with all phandle
>> property values auto generated, then the size required by the cache
>> could be 4 * (1 + number of phandles) bytes.  This results in an O(1)
>> node lookup cost for a given phandle value.  Due to a concern that the
>> phandle property values might not be consistent with what is generated
>> by the dtc compiler, a mask has been added to the cache lookup algorithm.
>> To maintain the O(1) node lookup cost, the size of the cache has been
>> increased by rounding the number of entries up to the next power of
>> two.
>>
>> The overhead of finding the devicetree node containing a given phandle
>> value has been noted by several people in the recent past, in some cases
>> with a patch to add a hashed index of devicetree nodes, based on the
>> phandle value of the node.  One concern with this approach is the extra
>> space added to each node.  This patch takes advantage of the phandle
>> property values auto generated by the dtc compiler, which begin with
>> one and monotonically increase by one, resulting in a range of 1..n
>> for n phandle values.  This implementation should also provide a good
>> reduction of overhead for any range of phandle values that are mostly
>> in a monotonic range.
>>
>> Performance measurements by Chintan Pandya <cpandya@codeaurora.org>
>> of several implementations of patches that are similar to this one
>> suggest an expected reduction of boot time by ~400ms for his test
>> system.  If the cache size was decreased to 64 entries, the boot
>> time was reduced by ~340 ms.  The measurements were on a 4.9.73 kernel
>> for arch/arm64/boot/dts/qcom/sda670-mtp.dts, contains 2371 nodes and
>> 814 phandle values.
>>
>> Reported-by: Chintan Pandya <cpandya@codeaurora.org>
>> Signed-off-by: Frank Rowand <frank.rowand@sony.com>
>> ---
> 
> I've applied this one, but not the others.
> 
> Rob
> 

Thank you.  I'll let the other two disappear into a distant memory.

-Frank

  reply	other threads:[~2018-03-10  1:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05  0:14 [PATCH v5 0/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() frowand.list
2018-03-05  0:14 ` [PATCH v5 1/3] " frowand.list
2018-03-09 23:03   ` Rob Herring
2018-03-10  1:20     ` Frank Rowand [this message]
2018-06-12 18:16   ` Alan Tull
2018-06-13 14:42     ` Alan Tull
2018-06-13 21:47       ` Frank Rowand
2018-06-14 20:59         ` Alan Tull
2018-08-30  0:44   ` v4.17 regression: PowerMac G3 won't boot, was " Finn Thain
2018-08-30  1:05     ` Rob Herring
     [not found]       ` <569e4bc3-2149-4b2d-562f-e400dd05a8a8@yahoo.com>
2018-08-31  4:35         ` Benjamin Herrenschmidt
2018-08-31  4:49           ` Benjamin Herrenschmidt
2018-08-31  4:49           ` Benjamin Herrenschmidt
2018-08-31  4:36     ` Frank Rowand
2018-08-31  4:58       ` Benjamin Herrenschmidt
2018-09-09 17:04         ` Benjamin Herrenschmidt
2018-09-09 23:52           ` Frank Rowand
2018-09-10 12:53           ` Rob Herring
2018-09-11 15:53             ` Frank Rowand
     [not found]             ` <abb0dec2-da3a-2c04-0e9f-28851b22cf75@yahoo.com>
2018-09-12  0:15               ` Finn Thain
2018-03-05  0:14 ` [PATCH v5 2/3] memblock: add memblock_free() alloc when CONFIG_HAVE_MEMBLOCK is not set frowand.list
2018-03-06  0:00   ` Andrew Morton
2018-03-05  0:14 ` [PATCH v5 3/3] of: add early boot allocation of of_find_node_by_phandle() cache frowand.list
2018-03-05 20:26   ` Rob Herring
2018-03-06  3:12     ` Frank Rowand

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=c2e23a6f-efb5-6476-4434-6f82c924c373@gmail.com \
    --to=frowand.list@gmail.com \
    --cc=cpandya@codeaurora.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).