From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:60970)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1VspNZ-0000LZ-TI
	for qemu-devel@nongnu.org; Tue, 17 Dec 2013 02:47:50 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1VspNV-0001HL-0w
	for qemu-devel@nongnu.org; Tue, 17 Dec 2013 02:47:45 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6882)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <armbru@redhat.com>) id 1VspNU-0001EH-PQ
	for qemu-devel@nongnu.org; Tue, 17 Dec 2013 02:47:40 -0500
From: Markus Armbruster <armbru@redhat.com>
References: <1386598213-8156-1-git-send-email-akong@redhat.com>
	<1386598213-8156-2-git-send-email-akong@redhat.com>
Date: Tue, 17 Dec 2013 08:47:34 +0100
In-Reply-To: <1386598213-8156-2-git-send-email-akong@redhat.com> (Amos Kong's
	message of "Mon, 9 Dec 2013 22:10:12 +0800")
Message-ID: <87txe7zzop.fsf@blackfin.pond.sub.org>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Qemu-devel] [PATCH RFC 1/2] rng-egd: improve egd backend
	performance
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Amos Kong <akong@redhat.com>
Cc: amit.shah@redhat.com, varadgautam@gmail.com, qemu-devel@nongnu.org, anthony@codemonkey.ws

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