12 ms·

A later comment says it affects versions through JB: Users are reporting this issue up through Jelly Bean / 4.2 - my specific information is against 4.2. I don

by bjustin 14y ago

A later comment says it affects versions through JB: Users are reporting this issue up through Jelly Bean / 4.2 - my specific information is against 4.2. I don't believe this issue was solved in gingerbread.

AndrewDucker 14y ago
We're seeing lots of people say "It's faster", but without some actual benchmarks I'm sceptical to say the least.
DannyBee 14y ago
This comment is wrong. As someone later shows, putting inotify waits on /dev/random shows nothing is opening it.
- mjg59 14y ago
  There are in-kernel consumers of entropy (such as for aslr) that wouldn't show up as /dev/random opens. Reading urandom will deplete the available entropy, but won't block - however, anything relying on actual entropy availability will then block until entropy is repopulated. So if entropy_avail is ever hitting 0, there's some vague plausibility that you could have some slowdowns. But honestly, it doesn't seem likely.
  - DannyBee 14y ago
    I could buy this, but i'd be surprised if it was in the very small percentage of code that is in android but not regular kernel. Past that, android workloads are certainly different, but i'd still think you'd see something outside of android.
- vidarh 14y ago
  It appears to be wrong that there's anything that reads /dev/random, yes. It is still correct that there are reports of latency reductions across the board. Whether or not they are real or placebo, or if they are real but have other causes (such as reboots) is another matter. But it's too easy to just dismiss this. I tried it on one of my tablets too, and din't reboot, and subjectively it feels substantially snappier - previously the UI would often freeze up long enough for me to get ANR dialogues, and the recommended solution for that tablet model is a full factory reset when it start being persistently slow. That does not mean that I'm sure the effect is real. Nor does it mean that it has to have anything to do with /dev/random.

by bjustin 14y ago

AndrewDucker 14y ago

We're seeing lots of people say "It's faster", but without some actual benchmarks I'm sceptical to say the least.

DannyBee 14y ago

This comment is wrong. As someone later shows, putting inotify waits on /dev/random shows nothing is opening it.

mjg59 14y ago
There are in-kernel consumers of entropy (such as for aslr) that wouldn't show up as /dev/random opens. Reading urandom will deplete the available entropy, but won't block - however, anything relying on actual entropy availability will then block until entropy is repopulated. So if entropy_avail is ever hitting 0, there's some vague plausibility that you could have some slowdowns. But honestly, it doesn't seem likely.
- DannyBee 14y ago
  I could buy this, but i'd be surprised if it was in the very small percentage of code that is in android but not regular kernel. Past that, android workloads are certainly different, but i'd still think you'd see something outside of android.
vidarh 14y ago
It appears to be wrong that there's anything that reads /dev/random, yes. It is still correct that there are reports of latency reductions across the board. Whether or not they are real or placebo, or if they are real but have other causes (such as reboots) is another matter. But it's too easy to just dismiss this. I tried it on one of my tablets too, and din't reboot, and subjectively it feels substantially snappier - previously the UI would often freeze up long enough for me to get ANR dialogues, and the recommended solution for that tablet model is a full factory reset when it start being persistently slow. That does not mean that I'm sure the effect is real. Nor does it mean that it has to have anything to do with /dev/random.