Hi, 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. Segher
