From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932594AbdIYC7k (ORCPT ); Sun, 24 Sep 2017 22:59:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57194 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932076AbdIYC7i (ORCPT ); Sun, 24 Sep 2017 22:59:38 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0C6104E4C6 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=ming.lei@redhat.com Date: Mon, 25 Sep 2017 10:59:24 +0800 From: Ming Lei To: Martin Steigerwald Cc: Oleksandr Natalenko , Jens Axboe , Christoph Hellwig , linux-block@vger.kernel.org, linux-raid@vger.kernel.org, linux-kernel@vger.kernel.org, Shaohua Li Subject: Re: I/O hangs after resuming from suspend-to-ram Message-ID: <20170925025917.GA7090@ming.t460p> References: <3926917.BCSovyVWdL@natalenko.name> <2260365.vTb2K2ZmgF@merkaba> <20170920221703.GA5105@ming.t460p> <9658713.A4bv0G9Yjl@merkaba> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9658713.A4bv0G9Yjl@merkaba> User-Agent: Mutt/1.8.3 (2017-05-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 25 Sep 2017 02:59:38 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 24, 2017 at 07:33:00PM +0200, Martin Steigerwald wrote: > Ming Lei - 21.09.17, 06:17: > > On Wed, Sep 20, 2017 at 07:25:02PM +0200, Martin Steigerwald wrote: > > > Ming Lei - 28.08.17, 21:32: > > > > On Mon, Aug 28, 2017 at 03:10:35PM +0200, Martin Steigerwald wrote: > > > > > Ming Lei - 28.08.17, 20:58: > > > > > > On Sun, Aug 27, 2017 at 09:43:52AM +0200, Oleksandr Natalenko wrote: > > > > > > > Hi. > > > > > > > > > > Here is disk setup for QEMU VM: > > > […] > > > > > > > > > > In words: 2 virtual disks, RAID10 setup with far-2 layout, LUKS on > > > > > > > it, > > > > > > > then > > > > > > > LVM, then ext4 for boot, swap and btrfs for /. > > > > > > > > > > > > > > I couldn't reproduce the issue with single disk without RAID. > > > > > > > > > > > > Could you verify if the following patch fixes your issue? > > > > > > > > > > Could this also apply to non MD RAID systems? I am using BTRFS RAID > > > > > 1 with two SSDs. So far with CFQ it runs stable. > > > > > > > > It is for fixing Oleksandr's issue wrt. blk-mq, and looks not for you. > > > > > > My findings are different: > > > > > > On 4.12.10 with CONFIG_HZ=1000, CONFIG_PREEMPT=y and optimizations for > > > Intel Core/newer Xeon I see this: > > > > > > 1) Running with CFQ: No hang after resume > > > > > > 2) Running with scsi_mod.use_blk_mq=1 + BFQ: Hang after resume within > > > first 1-2 days. > > > > Hi Martin, > > > > Thanks for your report! > > > > Could you test the following patchset to see if it fixes your issue? > > > > https://marc.info/?l=linux-block&m=150579298505484&w=2 > > Testing with https://github.com/ming1/linux.git, my_v4.13-safe-scsi- > quiesce_V5_for_test branch as of 53954fd58fb9fe6894b1635dad1acec96ca51a2f I > now have a bit more than three days and 8 hours of uptime without a hang on > resume from memory or disk, despite using blk-mq + BFQ. > > So it looks like this patch set fixes the issue for me. To say for sure I´d say > some more days of testing are needed. But it looks like the hang on resume is > fixed by this patch set. Martin, thanks for your test, it is great to see your issue is fixed by this patchset. Also I remember that your issue wasn't related with MD, and actually you were using BTRFS(RAID), just want to double check with you, is that true? -- Ming