From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlKUe-0003Y7-GT for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:24:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VlKUY-0007sB-Go for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:24:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:31170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VlKUY-0007s7-7o for qemu-devel@nongnu.org; Tue, 26 Nov 2013 10:23:58 -0500 Date: Tue, 26 Nov 2013 23:23:52 +0800 From: Amos Kong Message-ID: <20131126152352.GC29669@amosk.info> References: <1385473433-15844-1-git-send-email-akong@redhat.com> <5294A902.5060000@redhat.com> <5294B105.2080000@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZGiS0Q5IWpPtfppv" Content-Disposition: inline In-Reply-To: <5294B105.2080000@redhat.com> Subject: Re: [Qemu-devel] [PATCH] virtio-rng: correct the default limit rate List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: amit.shah@redhat.com, Paolo Bonzini , anthony@codemonkey.ws, qemu-devel@nongnu.org, "libvir-list@redhat.com" --ZGiS0Q5IWpPtfppv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 26, 2013 at 07:32:37AM -0700, Eric Blake wrote: > [adding libvirt] >=20 > On 11/26/2013 06:58 AM, Paolo Bonzini wrote: > > Il 26/11/2013 14:43, Amos Kong ha scritto: > >> /* Set a default rate limit of 2^47 bytes per minute or roughly 2TB/s.= If > >> * you have an entropy source capable of generating more entropy than = this > >> * and you can pass it through via virtio-rng, then hats off to you. = Until > >> * then, this is unlimited for all practical purposes. > >> */ > >> > >> But the current rate is (INT64_MAX) bytes per (1 << 16) ms, it's 128,0= 00 TB/s > >=20 > > You are changing: > >=20 > > * max-bytes from 2^63 to 2^47 > >=20 > > * period from 65536 to 60000 > >=20 > > For a user, changing only period would have no effect, the limit rate > > would remain effectively infinite. Changing max-bytes would give a 7% > > higher rate after your patch. > >=20 > > Not a big deal, and max-bytes is easier to explain after your patch > > (bytes/minute) than before (bytes/65536ms). > >=20 > > Reviewed-by: Paolo Bonzini > >=20 >=20 > Hmm. Libvirt is already converting a user's rate of bytes/period into > the qemu parameters, defaulting to 1 second as its default period. So libvirt will always pass a fixed 1 second period to qemu? > Am I > correct that as long as libvirt specified both rate AND period, then > this change has no impact (and that the 7% change occurs if you specify > period while leaving max-bytes alone)? > Or is this an ABI change where > libvirt will have to be taught to be smart enough to know whether it is > old qemu or new qemu to adjust how libvirt does its calculations when > converting the user's rate into qemu terms? Nothing need to do in Libvirt for _this patch_ No API change here, just change default rate from 1.9 TB/s to 2.1 TB/s This patch didn't change another limit logic. =3D=3D Effect of the period parameter =3D=3D When we set a fixed ratespeed, we can use different periods. The period still effect the stable of system IO.=20 If the period is too large, and we set a higher speed, then IO will wave. Example: the IO max speed is 20 M/s, and we test 5 mins it clear that the first period is better _Theory_ Condition: * period 1: 20M / 1s from 0 ~ 20 second, read packets, from 21 ~ 100 second, wait ... from 0 ~ 20 second, read packets, from 21 ~ 100 second, wait ... from 260 ~ 281 second, read packets, from 281 ~ 300 second, wait ... * period 2: 100M / 5 from 0 ~ 60 second, read packets, from 61 ~ 300 second, wait ... Smaller period is better, but smaller period will cause more timer expired, and IO wave will be balance by scheduling other process. So Libvirt should pass period & max-bytes in xml to qemu without converting. --=20 Amos. --ZGiS0Q5IWpPtfppv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBAgAGBQJSlL0IAAoJELxSv6I5vP9jSrcP/jFFQU8FtWO4kb40pHoj69Hf slVoKgHYs6rWxKep/8yJ2Uz6a1W6LOoscpU0mwJpMvCrN5xPuLtp2cvjpQ4ACtj6 qFMaLvuVObMvS2Gk09Rytk1GPfxgMgmhyXvUxQjzfAqq/KsorZbR6UF6JeM1o/AU pfPRsFZjzeAFmjCkwM4ArQLKHGB7uu3mpTFl+5cPz6Hs4Vn4epFlWSZn31r7+Hfb GOi2noDC/8CG78ADNvn4lQX88dW8SNsNw9+tme2nT66QByBCBlheQ5+lQFymx1Xg iG0w7RPkbBIUyUIfr+3NsIJNiLd1t56nuOQHy95KhVS1xARG/vt2P70wWvZIMnCt GjTiCFpz1et04DjdY5hbZUjYLqiO/nca1VDZpYdb+BmenwR/RWz29eWNmWKIBvod RX0VtgLTqx8COMAy+tUJlr4iYOiEOaVLi2Mg60yUGKJUiSaAnR0d8vroJlrugkSp Am3bhOIeM0zPf1fEQNhzUh90rJ6qXgmFq9sTF30kvqykaXJ4NEK+c8m6qFpiRBMK KGpRm0vQouZC3q8COwMogw/37dFWp88oW8zyqON1NjDx7dDlwvGwynjotJZ22xdw 5qZO54COmuLZDRR9dT6L6/AY4mpH1AfgSKGrzUmtcnu7zCWJWRobSeVE3w8JJfK9 c0v54Yjh/Zv+Aah5/Ifn =FKjH -----END PGP SIGNATURE----- --ZGiS0Q5IWpPtfppv--