From: frowand.list@gmail.com
To: Rob Herring <robh+dt@kernel.org>, cpandya@codeaurora.org
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
Date: Sun, 4 Mar 2018 16:14:46 -0800 [thread overview]
Message-ID: <1520208889-3908-1-git-send-email-frowand.list@gmail.com> (raw)
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.
Size and performance data is in patch 1/3 comments
Changes since v4:
- Add patch 2/3 "memblock: add memblock_free() alloc when
CONFIG_HAVE_MEMBLOCK is not set"
- patch 3/3 (previously 2/2): add checks for zero returned by
memblock_virt_alloc()
Changes since v3:
- of_populate_phandle_cache(): add check for failed memory allocation
- add patch 2/2 into series instead of as a standalone patch that was
dependent on patch 1/2 of this series
Changes since v2:
- add mask to calculation of phandle cache entry
- which results in better overhead reduction for devicetrees with
phandle properties not allocated in the monotonically increasing
range of 1..n
- due to mask, number of entries in cache potentially increased to
next power of two
- minor fixes as suggested by reviewers
- no longer using live_tree_max_phandle() so do not move it from
drivers/of/resolver.c to drivers/of/base.c
Changes since v1:
- change short description from
of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
- rebase on v4.16-rc1
- reorder new functions in base.c to avoid forward declaration
- add locking around kfree(phandle_cache) for memory ordering
- add explicit check for non-null of phandle_cache in
of_find_node_by_phandle(). There is already a check for !handle,
which prevents accessing a null phandle_cache, but that dependency
is not obvious, so this check makes it more apparent.
- do not free phandle_cache if modules are enabled, so that
cached phandles will be available when modules are loaded
Frank Rowand (3):
of: cache phandle nodes to reduce cost of of_find_node_by_phandle()
memblock: add memblock_free() alloc when CONFIG_HAVE_MEMBLOCK is not
set
of: add early boot allocation of of_find_node_by_phandle() cache
drivers/of/base.c | 124 +++++++++++++++++++++++++++++++++++++++++++++--
drivers/of/fdt.c | 2 +
drivers/of/of_private.h | 5 ++
drivers/of/resolver.c | 3 --
include/linux/memblock.h | 4 ++
5 files changed, 131 insertions(+), 7 deletions(-)
--
Frank Rowand <frank.rowand@sony.com>
next reply other threads:[~2018-03-05 0:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-05 0:14 frowand.list [this message]
2018-03-05 0:14 ` [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() frowand.list
2018-03-09 23:03 ` Rob Herring
2018-03-10 1:20 ` Frank Rowand
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=1520208889-3908-1-git-send-email-frowand.list@gmail.com \
--to=frowand.list@gmail.com \
--cc=cpandya@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@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).