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

[Amit Shah]

On (Tue) 17 Dec 2013 [08:47:34], Markus Armbruster wrote:
> 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?

It is a problem and we surely don't want such a problem.  So far, it
looks like we need to test this differently.  I'm not at all sure
these numbers will be meaningful once we get a proper test going.

                Amit