From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hermann Himmelbauer Subject: Re: Disk I/O stuck with KVM - no clue how to solve that Date: Mon, 8 Nov 2010 15:05:53 +0100 Message-ID: <201011081505.53540.dusty@qwer.tk> References: <201011051816.59032.dusty@qwer.tk> <201011071707.51508.dusty@qwer.tk> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Stefan Hajnoczi Return-path: Received: from mx11.lb01.inode.at ([62.99.145.13]:28298 "EHLO mx.inode.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754731Ab0KHOGD (ORCPT ); Mon, 8 Nov 2010 09:06:03 -0500 In-Reply-To: Content-Disposition: inline Sender: kvm-owner@vger.kernel.org List-ID: Am Montag 08 November 2010 07:32:39 schrieb Stefan Hajnoczi: > If you have the time, you can use perf probes to trace I/O requests in > the host kernel. Perhaps completion interrupts are being dropped. > You may wish to start by tracing requests issued and completed by the > SATA driver. Fortunately, some poster from the lkml suggested to set the SATA controller in the BIOS from IDE to AHCI, which I did and *maybe* it solved the problem. There are still some short blocks, but the overall read speed is stable (can be seen via iostats/iotop), so only the I/O read distribution between the host and KVM has some hiccups, but that seems to be tolerable for now. But thanks for your idea, if the problem comes back, perf probes may come handy! Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7