On Wed, Jan 08, 2014 at 09:53:02PM +0530, Amit Shah wrote: > 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.
Agree. The main reason is the slow source, using buffers and pre-reading is just abuse the resource & sync read API in qemu. > > 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. http://miketeo.net/wp/index.php/2009/06/09/egd-entropy-gathering-daemon-client-protocol.html > 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. We always recommend the users to use rng-random backend. Only use rng-egd backend when host uses a USB entropy device. Let's see if there exists some problem when the rng backend speed is about 5 kB/s. > Amit -- Amos.