Markus Armbruster <arm...@redhat.com> writes: > Amos Kong <ak...@redhat.com> writes: > >> Bugzilla: https://bugs.launchpad.net/qemu/+bug/1253563 >> >> We have a requests queue to cache the random data, but the second >> will come in when the first request is returned, so we always >> only have one items in the queue. It effects the performance. >> >> This patch changes the IOthread to fill a fixed buffer with >> random data from egd socket, request_entropy() will return >> data to virtio queue if buffer has available data. >> >> (test with a fast source, disguised egd socket) >> # cat /dev/urandom | nc -l localhost 8003 >> # qemu .. -chardev socket,host=localhost,port=8003,id=chr0 \ >> -object rng-egd,chardev=chr0,id=rng0,buf_size=1024 \ >> -device virtio-rng-pci,rng=rng0 >> >> bytes kb/s >> ------ ---- >> 131072 -> 835 >> 65536 -> 652 >> 32768 -> 356 >> 16384 -> 182 >> 8192 -> 99 >> 4096 -> 52 >> 2048 -> 30 >> 1024 -> 15 >> 512 -> 8 >> 256 -> 4 >> 128 -> 3 >> 64 -> 2 > > I'm not familiar with the rng-egd code, but perhaps my question has > value anyway: could agressive reading ahead on a source of randomness > cause trouble by depleting the source? > > Consider a server restarting a few dozen guests after reboot, where each > guest's QEMU then tries to slurp in a couple of KiB of randomness. How > does this behave?
I hit this performance problem while I was working on RNG devices support in virt-manager and I also noticed that the bottleneck is in the egd backend that slowly response to requests. I thought as well about adding a buffer but to handle it trough a new message type in the EGD protocol. The new message type informs the EGD daemon of the buffer size and that the buffer data has a lower priority that the daemon should fill when there are no other queued requests. Could such approach solve the scenario you've described? Cheers, Giuseppe