Re: [GIT PULL] Device tree updates for v3.12

From: Tim Bird
Date: Wed Sep 11 2013 - 16:21:21 EST


Thanks. This gives me an order-of-magnitude measurement for this sort of thing.
I'll measure it directly myself on our hardware as soon as I can.

I've heard an ugly rumor that the device tree from our silicon vendor
may grow to be
as big as 130K in the near future. I'm still following up to see if
there's any truth
to this (so don't quote me on it), but if it does get that big it
might be an issue. As
stated previously, the vast majority of our device tree files consists
of values that
are not device-specific.

I'll keep an eye on it and propose something if it turns out to be a real issue.


On Wed, Sep 11, 2013 at 10:02 AM, Tony Luck <tony.luck@xxxxxxxxx> wrote:
> On Tue, Sep 10, 2013 at 1:50 PM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>> Of course, maybe even the stupid add_device_randomness() is fast
>> enough. I just wanted to point out that it definitely isn't some
>> optimized thing.
>
> When I posted the patch that mixes in the whole SMBIOS table:
>
> commit d114a33387472555188f142ed8e98acdb8181c6d
> Author: Tony Luck <tony.luck@xxxxxxxxx>
> Date: Fri Jul 20 13:15:20 2012 -0700
>
> dmi: Feed DMI table to /dev/random driver
>
> I asked whether there was any size issue - as it tends to be a few
> kilobytes on laptops and desktops, and tens of kilobytes on servers.
> The answer I got back then was not to worry - digesting a few kilobytes
> wouldn't be a problem. I just threw in a debug message to check and saw:
>
> dmi_walk_early: added 10342 bytes in 339968 cycles
>
> So a couple of hundred microseconds for me.
>
> There are plenty of machine specific values buried in there (e.g. serial
> numbers for all the DIMMs) ... so this looks like a good use of this
> much boot time.
>
> -Tony



--
-- Tim Bird
Senior Software Engineer, Sony Mobile
Architecture Group Chair, CE Workgroup, Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/