On (Wed) 08 Jan 2014 [17:14:41], Amos Kong wrote: > On Wed, Dec 18, 2013 at 11:05:14AM +0100, Giuseppe Scrivano wrote: > > 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? > > Hi Giuseppe, > > > 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. > > o Current situation: > rng-random backend reads data from non-blocking character devices > New entropy request will be sent from guest when last request is processed, > so the request queue can only cache one request. > Almost all the request size is 64 bytes. > Egd socket responses the request slowly. > > o Solution 1: pre-reading, perf is improved, but cost much memory > In my V1 patch, I tried to add a configurable buffer to pre-read data > from egd socket. The performance was improved but it used a big memory > as the buffer.
I really dislike buffering random numbers or entropy from the host, let's rule these options out. > o Solution 2: pre-sending request to egd socket, improve is trivial > I did another test, we just pre-send entropy request to egd socket, not > really read the data to a buffer. > > o Solution 3: eyeless poll, not good > Always returns an integer in rng_egd_chr_can_read(), the perf can be > improved to 120 kB/s, it reduce the delay caused by poll mechanism. > > o Solution 4: > Try to use the new message type to improve the response speed of egd socket > > o Solution 5: > non-block read? I'd just say let the "problem" be. I don't really get the point of egd. The egd backend was something Anthony wanted, but I can't remember if there has been enough justification for it. Certainly the protocol isn't documented, and not using the backend doesn't give us drawbacks. Moreover, reasonable guests won't request for a whole lot of random numbers in a short interval, so the theoretical performance problem we're seeing is just going to remain theoretical for well-behaved guests. We have enough documentation by now about this issue, I say let's just drop this patch and worry about this only if there's a proven need to better things here. Amit