From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33229) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UO30r-00021y-Kr for qemu-devel@nongnu.org; Fri, 05 Apr 2013 05:32:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UO30h-0007Ro-0B for qemu-devel@nongnu.org; Fri, 05 Apr 2013 05:32:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UO30g-0007RG-P8 for qemu-devel@nongnu.org; Fri, 05 Apr 2013 05:32:38 -0400 From: Stefan Hajnoczi Date: Fri, 5 Apr 2013 11:32:18 +0200 Message-Id: <1365154342-10513-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] [PATCH v2 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. Tested-By: Benoit Canet v2: * Account slice_submitted after both bps and iops checks pass [kwolf] 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 | 49 +++++++++++++++++++++--------------------= ------ blockdev.c | 1 - include/block/block_int.h | 3 +-- 3 files changed, 23 insertions(+), 30 deletions(-) --=20 1.8.1.4