From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIgp7-0003AE-Qo for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:50:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIgp2-0002Hw-By for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:50:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:64793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIgp2-0002HU-4q for qemu-devel@nongnu.org; Thu, 21 Mar 2013 10:50:28 -0400 From: Stefan Hajnoczi Date: Thu, 21 Mar 2013 15:49:55 +0100 Message-Id: <1363877399-16339-1-git-send-email-stefanha@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] [RFC 0/4] block: fix I/O throttling oscillations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Kevin Wolf , =?UTF-8?q?Beno=C3=AEt=20Canet?= , Stefan Hajnoczi , Zhi Yong Wu Beno=C3=AEt Canet reported that QEMU I/O throttling = can oscillate under continuous I/O. The test case runs 50 threads performing random writes and a -drive iops=3D150 limit is used. Since QEMU I/O throttling is implemented using 100 millisecond time slice= s, we'd expect 150 +/- 15 IOPS. Anything outside that range indicates a pro= blem with the I/O throttling algorithm. It turned out that even a single thread performing sequential I/O continu= ously is throttled outside the 150 +/- 15 IOPS range. The continous stream of = I/O slows down as time goes on but resets to 150 IOPS again when interrupted.= This can be tested with: $ iostat -d 1 -x /dev/vdb & $ dd if=3D/dev/vdb of=3D/dev/null bs=3D4096 iflag=3Ddirect This patches addresses these problems as follows: 1. Account for I/O requests when they are submitted instead of completed.= This ensures that we do not exceed the budget for this slice. Exceeding th= e budget leads to fluctuations since we have to make up for this later. 2. Use constant 100 millisecond slice time. Adjusting the slice time at run-time led to oscillations. Since the reason for adjusting slice ti= me is not clear, drop this behavior. I have also included two code clean-up patches. Beno=C3=AEt: Please let me know if this solves the problems you're seeing. Stefan Hajnoczi (4): block: fix I/O throttling accounting blind spot block: keep I/O throttling slice time constant block: drop duplicated slice extension code block: clean up I/O throttling wait_time code block.c | 47 ++++++++++++++++++++---------------------= ------ blockdev.c | 1 - include/block/block_int.h | 3 +-- 3 files changed, 21 insertions(+), 30 deletions(-) --=20 1.8.1.4