From: Chintan Pandya <cpandya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Frank Rowand
<frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle()
Date: Fri, 2 Feb 2018 11:23:26 +0530 [thread overview]
Message-ID: <cae45760-558d-c0b7-93aa-a137f46b2836@codeaurora.org> (raw)
In-Reply-To: <4f2b3755-9ef1-4817-7436-9f5aafb38b60-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2/2/2018 2:39 AM, Frank Rowand wrote:
> On 02/01/18 06:24, Rob Herring wrote:
>> And so
>> far, no one has explained why a bigger cache got slower.
>
> Yes, I still find that surprising.
I thought a bit about this. And realized that increasing the cache size
should help improve the performance only if there are too many misses
with the smaller cache. So, from my experiments some time back, I looked
up the logs and saw the access pattern. Seems like, there is
*not_too_much* juggling during look up by phandles.
See the access pattern here:
https://drive.google.com/file/d/1qfAD8OsswNJABgAwjJf6Gr_JZMeK7rLV/view?usp=sharing
Sample log is pasted below where number in the last is phandle value.
Line 8853: [ 37.425405] OF: want to search this 262
Line 8854: [ 37.425453] OF: want to search this 262
Line 8855: [ 37.425499] OF: want to search this 262
Line 8856: [ 37.425549] OF: want to search this 15
Line 8857: [ 37.425599] OF: want to search this 5
Line 8858: [ 37.429989] OF: want to search this 253
Line 8859: [ 37.430058] OF: want to search this 253
Line 8860: [ 37.430217] OF: want to search this 253
Line 8861: [ 37.430278] OF: want to search this 253
Line 8862: [ 37.430337] OF: want to search this 253
Line 8863: [ 37.430399] OF: want to search this 254
Line 8864: [ 37.430597] OF: want to search this 254
Line 8865: [ 37.430656] OF: want to search this 254
Above explains why results with cache size 64 and 128 have almost
similar results. Now, for cache size 256 we have degrading performance.
I don't have a good theory here but I'm assuming that by making large SW
cache, we miss the benefits of real HW cache which is typically smaller
than our array size. Also, in my set up, I've set max_cpu=1 to reduce
the variance. That again, should affect the cache holding pattern in HW
and affect the perf numbers.
Chintan
--
Qualcom India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-02-02 5:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 20:05 [PATCH] of: cache phandle nodes to decrease cost of of_find_node_by_phandle() frowand.list
2018-01-31 20:10 ` Frank Rowand
[not found] ` <1517429142-25727-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-31 21:43 ` Frank Rowand
[not found] ` <5dd35d8f-c430-237e-9863-2e73556f92ec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-02-01 14:24 ` Rob Herring
[not found] ` <CAL_JsqLV_bQ2pQ7hCRDP9_31kmKQjggWFDoCia-KmmO5CR3T5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-01 14:26 ` Rob Herring
2018-02-01 21:09 ` Frank Rowand
2018-02-02 3:45 ` Rob Herring
2018-02-02 22:34 ` Frank Rowand
[not found] ` <4f2b3755-9ef1-4817-7436-9f5aafb38b60-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-02-02 5:53 ` Chintan Pandya [this message]
2018-02-03 3:55 ` Frank Rowand
2018-02-01 6:45 ` Chintan Pandya
2018-02-01 8:59 ` Frank Rowand
[not found] ` <38cdcae5-ec0f-d1be-b024-1990d4387731-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-02-01 10:31 ` Chintan Pandya
[not found] ` <9e23d32f-05a0-ce8a-41f8-9a1a3d66be37-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-01 19:10 ` Frank Rowand
[not found] ` <fd9f5f63-b08e-602e-1510-85a65889f550-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-02-02 5:59 ` Chintan Pandya
[not found] ` <567731e8-8f89-bd6e-c3d4-e36400e69198-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-02 21:26 ` Frank Rowand
2018-02-05 12:23 ` Chintan Pandya
[not found] ` <0a178f4b-75fe-0564-7b0e-596f52fca1dc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-07 12:44 ` Chintan Pandya
[not found] ` <1768c791-7456-c1fe-578b-f6245e79746f-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2018-02-07 20:09 ` Frank Rowand
2018-02-01 14:34 ` Rob Herring
2018-02-01 21:13 ` Frank Rowand
-- strict thread matches above, loose matches on Subject: below --
2018-01-31 20:02 frowand.list-Re5JQEeQqe8AvxtiuMwx3w
[not found] ` <1517428977-25653-1-git-send-email-frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2018-01-31 20:07 ` 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=cae45760-558d-c0b7-93aa-a137f46b2836@codeaurora.org \
--to=cpandya-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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).