Date: Fri, 12 May 2017 11:29:19 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219216] sched_bind() blocks if the entropy pool is starved Message-ID: <bug-219216-8-SKqNIufRii@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219216-8@https.bugs.freebsd.org/bugzilla/> References: <bug-219216-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219216 Fabian Keil <fk@fabiankeil.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fk@fabiankeil.de --- Comment #9 from Fabian Keil <fk@fabiankeil.de> --- I can't reproduce the issue either. I'm using a kernel based on r318145: CPU: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz (2491.96-MHz K8-class CPU) I let the script run through 1680 cycles without noticeable issues. While dd keeps a core busy as expected, rand_harvestq stays below 3% cpu use according to top. I use vanilla powerd(8) which changes the cpu frequency between 800 and 2501. The fact that rand_harvestq is busy doesn't necessarily indicate that the entropy pool is starved. You could try running: sudo dtrace -n 'fbt:kernel:random_harvest_*:entry {@[probefunc, stack()] =3D count(); } tick-60sec {exit(0)}' to see which random_harvest_* functions are called, from where and how ofte= n. Additionally you could experiment with modifying the entropy sources with: kern.random.harvest.mask to see if it makes a difference. Newly harvested entropy is mixed into the pool so adding more shouldn't lower the "entropy quality" in the pool. Therefore it's not obvious to me h= ow the "poisoning" you mentioned would work. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219216-8-SKqNIufRii>