From: Peter Lieven Subject: Re: qemu-kvm hangs if multipath device is queing Date: Wed, 19 May 2010 10:18:08 +0200 Message-ID: <4BF39EC0.8000007@dlh.net> References: <4BDF3F94.1080608@dlh.net> <4BDFDC44.9030808@redhat.com> <4BE00750.6040804@dlh.net> <4BE01120.30608@redhat.com> <4BE02440.6010802@dlh.net> <4BE028BF.1000603@redhat.com> <4BEAB4B0.70803@dlh.net> <4BED1740.1080604@redhat.com> <4BF275B1.8030106@dlh.net> <4BF2949C.8010108@redhat.com> <20100519072902.GA711@lst.de> <4BF397DF.2030108@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , qemu-devel@nongnu.org, kvm@vger.kernel.org To: Kevin Wolf Return-path: Received: from zion.dlh.net ([91.198.192.1]:38971 "EHLO mail.dlh.net" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751518Ab0ESIS0 (ORCPT ); Wed, 19 May 2010 04:18:26 -0400 In-Reply-To: <4BF397DF.2030108@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Kevin Wolf wrote: > Am 19.05.2010 09:29, schrieb Christoph Hellwig: > >> On Tue, May 18, 2010 at 03:22:36PM +0200, Kevin Wolf wrote: >> >>> I think it's stuck here in an endless loop: >>> >>> while (laiocb->ret == -EINPROGRESS) >>> qemu_laio_completion_cb(laiocb->ctx); >>> >>> Can you verify this by single-stepping one or two loop iterations? ret >>> and errno after the read call could be interesting, too. >>> >> Maybe the compiler is just too smart. Without some form of barrier >> it could just optimize the loop away as laiocb->ret couldn't change >> in a normal single-threaded environment. >> > > It probably could in theory, but in practice we're in a read() inside > qemu_laio_completion, so it didn't do it here. > if you supply a patch that will add some usleeps at the point in question i'm willing to test if it solves the 100% cpu problem. > Kevin > >