From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53065) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtE0K-00050s-2z for qemu-devel@nongnu.org; Wed, 18 Dec 2013 05:05:29 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtE0E-0003QC-I8 for qemu-devel@nongnu.org; Wed, 18 Dec 2013 05:05:24 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57092) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtE0E-0003Q8-Er for qemu-devel@nongnu.org; Wed, 18 Dec 2013 05:05:18 -0500 From: Giuseppe Scrivano References: <1386598213-8156-1-git-send-email-akong@redhat.com> <1386598213-8156-2-git-send-email-akong@redhat.com> <87txe7zzop.fsf@blackfin.pond.sub.org> Date: Wed, 18 Dec 2013 11:05:14 +0100 In-Reply-To: <87txe7zzop.fsf@blackfin.pond.sub.org> (Markus Armbruster's message of "Tue, 17 Dec 2013 08:47:34 +0100") Message-ID: <87d2ku325h.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend performance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: amit.shah@redhat.com, anthony@codemonkey.ws, Amos Kong , qemu-devel@nongnu.org, varadgautam@gmail.com Markus Armbruster writes: > Amos Kong 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