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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
