From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=36219 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OEfPL-0005gb-AQ
	for qemu-devel@nongnu.org; Wed, 19 May 2010 05:17:44 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <pl@dlh.net>) id 1OEfPJ-0001bu-Lo
	for qemu-devel@nongnu.org; Wed, 19 May 2010 05:17:43 -0400
Received: from zion.dlh.net ([91.198.192.1]:36638 helo=mail.dlh.net)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <pl@dlh.net>)
	id 1OEeTv-0000kZ-Fn
	for qemu-devel@nongnu.org; Wed, 19 May 2010 04:18:23 -0400
Message-ID: <4BF39EC0.8000007@dlh.net>
Date: Wed, 19 May 2010 10:18:08 +0200
From: Peter Lieven <pl@dlh.net>
MIME-Version: 1.0
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>
In-Reply-To: <4BF397DF.2030108@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Re: qemu-kvm hangs if multipath device is queing
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, kvm@vger.kernel.org, qemu-devel@nongnu.org

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
>
>