archive mirror
 help / color / mirror / Atom feed
From: Segher Boessenkool <>
To: Frank Rowand <>
Cc: Michael Ellerman <>,
	Sebastian Andrzej Siewior <>,,,
	Rob Herring <>,
	Benjamin Herrenschmidt <>,
	Paul Mackerras <>,
	Thomas Gleixner <>
Subject: Re: [RFC] Efficiency of the phandle_cache on ppc64/SLOF
Date: Fri, 6 Dec 2019 17:40:34 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


On Thu, Dec 05, 2019 at 07:37:24PM -0600, Frank Rowand wrote:
> On 12/3/19 12:35 PM, Segher Boessenkool wrote:
> > Btw.  Some OFs mangle the phandles some way, to make it easier to catch
> > people using it as an address (and similarly, mangle ihandles differently,
> > so you catch confusion between ihandles and phandles as well).  Like a
> > simple xor, with some odd number preferably.  You should assume *nothing*
> > about phandles, they are opaque identifiers.
> For arm32 machines that use dtc to generate the devicetree, which is a
> very large user base, we certainly can make assumptions about phandles.

I was talking about OF.  Phandles are explicitly defined to be opaque
tokens.  If there is an extra meaning to them in flattened device trees,
well, the kernel should then only depend on that there, not for more
general phandles.  Where is this documented btw?

> Especially because the complaints about the overhead of phandle based
> lookups have been voiced by users of this specific set of machines.
> For systems with a devicetree that does not follow the assumptions, the
> phandle cache should not measurably increase the overhead of phandle
> based lookups.

It's an extra memory access and extra code to execute, for not much gain
(if anything).  While with a reasonable hash function it will be good
for everyone.

> If you have measurements of a system where implementing the phandle
> cache increased the overhead,

Are you seriously saying you think this code can run in zero time and
space on most systems?

> and the additional overhead is a concern
> (such as significantly increasing boot time) then please share that
> information with us.  Otherwise this is just a theoretical exercise.

The point is that this code could be easily beneficial for most (or all)
users, not just those that use dtc-constructed device trees.  It is
completely obvious that having a worse cache hash function results in
many more lookups.  Whether that results in something expressed as
milliseconds on tiny systems or microseconds on bigger systems is
completely beside the point.


  reply	other threads:[~2019-12-06 23:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-29 15:10 [RFC] Efficiency of the phandle_cache on ppc64/SLOF Sebastian Andrzej Siewior
2019-11-30  2:14 ` Frank Rowand
2019-12-02 11:07   ` Sebastian Andrzej Siewior
2019-12-03  4:12   ` Michael Ellerman
2019-12-03  4:28     ` Frank Rowand
2019-12-03 16:56       ` Rob Herring
2019-12-05 16:35         ` Sebastian Andrzej Siewior
2019-12-06  2:01           ` Frank Rowand
2019-12-09 13:35             ` Sebastian Andrzej Siewior
2019-12-10  1:51               ` Rob Herring
2019-12-10  8:17                 ` Frank Rowand
2019-12-10 12:46                   ` Frank Rowand
2019-12-11 14:42                   ` Rob Herring
2019-12-06  1:52         ` Frank Rowand
2019-12-08  6:59           ` Frank Rowand
2019-12-03  4:03 ` Michael Ellerman
2019-12-03 18:35   ` Segher Boessenkool
2019-12-06  1:37     ` Frank Rowand
2019-12-06 23:40       ` Segher Boessenkool [this message]
2019-12-08  4:30         ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \

* 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).