From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:43983)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1T3inI-0000bR-IZ
	for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1T3inG-0006C0-Rf
	for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:32 -0400
Received: from mail.profihost.ag ([85.158.179.208]:40279)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <s.priebe@profihost.ag>) id 1T3inG-0006BQ-Gf
	for qemu-devel@nongnu.org; Tue, 21 Aug 2012 03:22:30 -0400
Message-ID: <50333731.6030203@profihost.ag>
Date: Tue, 21 Aug 2012 09:22:25 +0200
From: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>
MIME-Version: 1.0
References: <1345326543-10677-1-git-send-email-pbonzini@redhat.com>
	<50309BEE.3090602@profihost.ag> <5030E5F2.7060903@redhat.com>
	<50313D03.8040101@profihost.ag> <5031E5CC.7090306@redhat.com>
	<5031E86F.2000000@profihost.ag> <5031F060.1030602@redhat.com>
	<5031F15D.7050307@profihost.ag>
	<CAN05THQ=pkVu7Ei-ayx4LVzDgH5fJ-DxRmRizGCaYTt6FLdD3w@mail.gmail.com>
In-Reply-To: <CAN05THQ=pkVu7Ei-ayx4LVzDgH5fJ-DxRmRizGCaYTt6FLdD3w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH RFT 0/3] iscsi: fix NULL dereferences /
 races between task completion and abort
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org

Am 21.08.2012 00:36, schrieb ronnie sahlberg:
> On Mon, Aug 20, 2012 at 6:12 PM, Stefan Priebe - Profihost AG
> <s.priebe@profihost.ag> wrote:
>> Hi Ronnie,
>>
>> Am 20.08.2012 10:08, schrieb Paolo Bonzini:
>>
>>> That's because the "big QEMU lock" is held by the thread that called
>>> qemu_aio_cancel.
>>>
>>>> and i also see
>>>> no cancellation message in kernel log.
>>>
>>>
>>> And that's because the UNMAP actually ultimately succeeds.  You'll
>>> probably see soft lockup messages though.
>>>
>>> The solution here is to bump the timeout of the UNMAP command (either in
>>> the kernel or in libiscsi, I didn't really understand who's at fault).
>>
>>
>> What's your suggestion / idea about that?
>>
>
> There are no timeouts in libiscsi itself.
> But you can probably tweak it through the guest kernel :
>
>
> $ cat /sys/bus/scsi/devices/0\:0\:0\:0/timeout
> 30
>
> should be the default scsi timeout for this device, and
>
> $ cat /sys/bus/scsi/devices/0\:0\:0\:0/queue_depth
> 31
>
> would be how many concurrent i/o that the guest will drive to the device.
>
>
> When performing the UNMAPS, maybe setting timeout to something really
> big, and at the same time also dropping queue-depth to something
> really small so that the guest kernel will not be able to send so many
> UNMAPs concurrently.

How is this relevant to the fact, that i can't even work with SSH any 
longer with paolo's patch while UNMAPs are running? With my patchset you 
can still work on the machine.

Greets,
Stefan