--PEIAKu/WMn1b1Hv9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 20, 2012 at 07:58:51AM -0400, John Baldwin wrote: > On Thursday, September 20, 2012 6:21:04 am Pawel Jakub Dawidek wrote: > > I agree, we should do such analysis for much more devices and different > > kind of devices. A platform might be an important factor as well. > > It is hard to collect decent number of probes when reboot is needed, so > > what I'd recommend is to turn of SMP, boot into single module and > > kldload/kldunload a driver in a loop, of course with kernel patched to > > log those times. >=20 > This is not always representative. Any driver that uses a config intrhook > will run that synchronously during attach() in single user mode but will > not during boot. config intrhook's often go out and do things that take a > variable amount of time (poking hardware, waiting for interrupts, etc.). > That means that timing any such drivers from single user mode will likely > give you more variable attach() times than would occur during boot. Ok, to verify that I implemented some dummy driver that simply returns 0 on device_attach() and does nothing more. Additionally during probe I call device_quiet(dev). It turned out that printing device description during device_attach() over serial console (115200) make the call few orders of magnitude longer:), which in turn provides much more entropy so I wanted to avoid that. I booted the machine with SMP disabled and in single-user mode. I gathered 162833 samples: http://people.freebsd.org/~pjd/misc/device_attach_total_time.txt The values were between 15 and 16 bits, but to simplify things I assumed they are all 16 bits. I discarded top ten bits. This left me with 6bit values [0-63]: http://people.freebsd.org/~pjd/misc/device_attach_6bit.txt I compared empirical distribution with theoretical one and I got this: http://people.freebsd.org/~pjd/misc/device_attach_6bit.jpg Source in libreoffice: http://people.freebsd.org/~pjd/misc/device_attach_6bit.ods Mariusz can verify my findings here, but it looks like discarding top ten bits is enough even for very dummy drivers that don't interact with hardware at all. Note that discarding top ten bits effectively means that we expect 0.1% of the total device_attach() time to be unpredictably different. If discarding top ten bit in case of such dummy driver is enough, we could probably discard less from drivers that interact with real hardware, but even with 43 device_attach() calls during boot on similar hardware and assuming that we can get only 6 bits of entropy from each call, it gives us more than 256 bits of entropy. In other words I don't think we should further complicate this and that we should stick to entropy estimations from my current patch. Having similar tests for different architectures would be of course very welcome. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --PEIAKu/WMn1b1Hv9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBdcMcACgkQForvXbEpPzThLwCdHtCMTdgPjYCPmi7FShi1X8Wv 90MAn3Ldd/1fzymsgNeaUK+pa4kcCcB1 =n8Ic -----END PGP SIGNATURE----- --PEIAKu/WMn1b1Hv9--