From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E3C9C433B4 for ; Tue, 27 Apr 2021 09:12:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 08C46613B1 for ; Tue, 27 Apr 2021 09:12:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230354AbhD0JNW (ORCPT ); Tue, 27 Apr 2021 05:13:22 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:48585 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235088AbhD0JNS (ORCPT ); Tue, 27 Apr 2021 05:13:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1619514718; 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: in-reply-to:in-reply-to:references:references; bh=NnYQaX86Fcj9dAhMK+QIJGBc66dkfVgpeHVX/OOPAyQ=; b=g9NrL/iHydOugIglKFxSzA484US+Ni5z3LyYToiHpr3PtFh8Wf+WgAcyO/7yZA7wki/flf 51toa+K3A4mNXobHJHm9LNlIzmK+pBCqz3LYRPXMsId5jqklbVQy0pOLII9VvWeN4hZZHP 3Y0+693W8vVFr/AMMVUl+uMtuXV86w8= 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-334-IUbn19S9MYCpzssk2HszLw-1; Tue, 27 Apr 2021 05:11:54 -0400 X-MC-Unique: IUbn19S9MYCpzssk2HszLw-1 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 A81D6106BAE8; Tue, 27 Apr 2021 09:11:52 +0000 (UTC) Received: from T590 (ovpn-13-248.pek2.redhat.com [10.72.13.248]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 722C06E50A; Tue, 27 Apr 2021 09:11:41 +0000 (UTC) Date: Tue, 27 Apr 2021 17:11:49 +0800 From: Ming Lei To: John Garry Cc: Kashyap Desai , linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, "Martin K. Petersen" , Jens Axboe , Douglas Gilbert , Hannes Reinecke Subject: Re: [bug report] shared tags causes IO hang and performance drop Message-ID: References: <87ceccf2-287b-9bd1-899a-f15026c9e65b@huawei.com> <0c85fe52-ebc7-68b3-2dbe-dfad5d604346@huawei.com> <55743a51-4d6f-f481-cebf-e2af9c657911@huawei.com> <9ad15067-ba7b-a335-ae71-8c4328856b91@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Tue, Apr 27, 2021 at 08:52:53AM +0100, John Garry wrote: > On 27/04/2021 00:59, Ming Lei wrote: > > > Anyway, I'll look at adding code for a per-request queue sched tags to see > > > if it helps. But I would plan to continue to use a per hctx sched request > > > pool. > > Why not switch to per hctx sched request pool? > > I don't understand. The current code uses a per-hctx sched request pool, and > I said that I don't plan to change that. I forget why you didn't do that, because for hostwide tags, request is always 1:1 for either sched tags(real io sched) or driver tags(none). Maybe you want to keep request local to hctx, but never see related performance data for supporting the point, sbitmap queue allocator has been intelligent enough to allocate tag freed from native cpu. Then you just waste lots of memory, I remember that scsi request payload is a bit big. Thanks, Ming