Re: [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend performance

[Markus Armbruster]

Amos Kong <address@hidden> 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?