Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp4380199ybx; Sat, 9 Nov 2019 14:31:35 -0800 (PST) X-Google-Smtp-Source: APXvYqxG45xVUskDwuTL/5+tqCMr3jFZWCz1yk/8NfwBAzNWipIiGkAUJIUQxzm2fsLVolB0+87O X-Received: by 2002:a05:6402:339:: with SMTP id q25mr18601933edw.80.1573338695452; Sat, 09 Nov 2019 14:31:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573338695; cv=none; d=google.com; s=arc-20160816; b=wWmu/GXVxdTvI9edzkLJGl/3TS9pEX0E8yUO7maoLe8jb6gozmhjXI6tnCR4hGY0yP r4PHJkM8vs3wQliKOHr1/5DI89BIANTI5xgv33IVTy1JSmoxlnDqMXqytUe/oOHHlGcW 3bzPDpfPxsReEAHfJ9fojsOm89ISEbv2tXXc0zFb5NDRw8T0g1GowOY9gn1Czyv/Uuel 3qmd/nyYwtvRN2DksJfHaHgQJudbF4cFalGZQvKHV/URDtEw7M9CyU73peS5x0Ap4Auo VnkB7x7pU4eNnXi+MCl14JWISwASBG4leyd9rzWcZH165fsVK0evD/BE1Ofb021etERv OsvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-disposition :content-transfer-encoding:user-agent:in-reply-to:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=9oSogd1HclYTh4TochWGFDAg+DdvKpv0K/UpcRLncNQ=; b=JAbccdRXSxclLv0RW5FWbzPfp33WVDIOx3UI31vCOSvUiOqY4nLyX2ZN8IKu07+hJB YrOiXBCOvevBXLJiL/YLEBPnAAU+pvpiPgSC9kxY/1lpY/HdFS7S2nL+ku19+obTSKMe ReLO+5ZewMRsTriTlAbNoC+4FnND7Y4JXtzmSOS1LuO6KdJcILUFegG9Xs9KXDn20ueR Lh30aQuf1j0h31ZOEpoTOl7U1FTvq5Ez+RFQLr04Fbs5ReyIgoCcQE66O7ArhL4RsK47 8/OGeuudMfvNWckq7PAHzt7vIfBhr2SsxIsjAsmLCH7si4i18cmAoK3y3O17HiHQccb/ bt2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WhrJ7Ost; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f12si8477648edc.1.2019.11.09.14.30.58; Sat, 09 Nov 2019 14:31:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WhrJ7Ost; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726582AbfKIW2w (ORCPT + 99 others); Sat, 9 Nov 2019 17:28:52 -0500 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:53309 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726467AbfKIW2w (ORCPT ); Sat, 9 Nov 2019 17:28:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1573338530; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9oSogd1HclYTh4TochWGFDAg+DdvKpv0K/UpcRLncNQ=; b=WhrJ7Ost4/wmId144i0InrnyxLiMEuBEa9Mi54r8AIC5XK342QypLQ+7Z4ic4mg1t+FDFJ seBNmzG+Dhc+0ps5SapNiHStIFnCoMFPOHnFWwfUT3gLMJaNUwzuqc4AoUKcNmgIyixIJ5 j4+Z9vwVJXbyb88xOPItGzPo6xNhNdQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-46-PhgiX5CtNoOzD6MkuoOuLQ-1; Sat, 09 Nov 2019 17:28:47 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 41DA480183C; Sat, 9 Nov 2019 22:28:44 +0000 (UTC) Received: from ming.t460p (ovpn-8-17.pek2.redhat.com [10.72.8.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F580608B9; Sat, 9 Nov 2019 22:28:34 +0000 (UTC) Date: Sun, 10 Nov 2019 06:28:28 +0800 From: Ming Lei To: Andrea Vai Cc: Damien Le Moal , Alan Stern , Jens Axboe , Johannes Thumshirn , USB list , SCSI development list , Himanshu Madhani , Hannes Reinecke , Omar Sandoval , "Martin K. Petersen" , Greg KH , Hans Holmberg , Kernel development list Subject: Re: Slow I/O on USB media after commit f664a3cc17b7d0a2bc3b3ab96181e1029b0ec0e6 Message-ID: <20191109222828.GA30568@ming.t460p> References: MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: PhgiX5CtNoOzD6MkuoOuLQ-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 07, 2019 at 07:59:44PM +0100, Andrea Vai wrote: > [Sorry for the duplicate message, it didn't reach the lists due to > html formatting] > Il giorno gio 7 nov 2019 alle ore 08:54 Damien Le Moal > ha scritto: > > > > On 2019/11/07 16:04, Andrea Vai wrote: > > > Il giorno mer, 06/11/2019 alle 22.13 +0000, Damien Le Moal ha scritto= : > > >> > > >> > > >> Please simply try your write tests after doing this: > > >> > > >> echo mq-deadline > /sys/block/ > >> disk>/queue/scheduler > > >> > > >> And confirm that mq-deadline is selected with: > > >> > > >> cat /sys/block//queue/scheduler > > >> [mq-deadline] kyber bfq none > > > > > > ok, which kernel should I test with this: the fresh git cloned, or th= e > > > one just patched with Alan's patch, or doesn't matter which one? > > > > Probably all of them to see if there are any differences. >=20 > with both kernels, the output of > cat /sys/block/sdh/queue/schedule >=20 > already contains [mq-deadline]: is it correct to assume that the echo > command and the subsequent testing is useless? What to do now? Another thing we could try is to use 'none' via the following command: echo none > /sys/block/sdh/queue/scheduler #suppose 'sdh' points to the u= sb storage disk Because USB storage HBA is single hw queue, which depth is 1. This way should change to dispatch IO in the order of bio submission. Andrea, could you switch io scheduler to none and update us if difference can be made? Thanks, Ming