Received: by 2002:a05:6358:9144:b0:117:f937:c515 with SMTP id r4csp11174385rwr; Fri, 12 May 2023 21:24:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ53W3h0neC+WPfusKSK8O+xKTxUafl+Ppi6YxZ1NOqnsSFInSqqc3mQhjHcohbFx1dvlpCF X-Received: by 2002:a05:6a20:429b:b0:ff:ed6b:4c9e with SMTP id o27-20020a056a20429b00b000ffed6b4c9emr28686207pzj.36.1683951889134; Fri, 12 May 2023 21:24:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1683951889; cv=none; d=google.com; s=arc-20160816; b=KY4OT+w7CHnZcLcig36sf4oQLomZMiTchF5E0gaD2fIaImOpaIr5KZcl1nswBB7Vw2 uWam3NQ4LKxlxJyjWVAW1dHXQoMYztpNgFzaboUZMn0jTeU1x1PaohO98KMA+pSk2NTE rS2ZVV79ZM/mwiIYeT72niC1CZGwu5P2TJXJz6Dvz8BzLFA5QpfWyDYXGPXMonaBp2xk Cblqx5X/rhAwSQSipnYpvUkp6LlwNYw3x0/n9Yr8eHYNWeLaGZHu12D0gCVnXA2t1ydy sfbNIVp7mjOUcctxK2l8u1SzCXS1lr+XSp18x/p158EiPifgnTmkigAJXoTpWGguiclT yQIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=+AHxSk4m5SNcCup/TKX6kL7kRYpSjP8wgsujkbDLu0M=; b=Ba8aEDC95TMJrjqXlaRPx/gsQKiVL0qJl//VhQAeDVqIAGFQk5kP1M0+h0TylNdjMe pfImp/OOv1qfQnOngP5bn5SjiQ7yOizBD5MYtu/qJmSovgaBlK6knF0nsEWSweNAyRxb aAJnuQJJK5aoTT2UaTx0Z3T2QiTLy0yxyx4IsBIhb3IN+2lRVKjzLuF9P1i65x2LdJIx kRaPwSG0Ok1ClPmAOqBhYuOlgl8VIQXGSZbR3pjehfr5fZlc2A4hPyXsLPC2xHLvA15+ BQcHldJLzYpdvmGvdGEWkg6fOhBfiCTGp9K6NXbB9/TANfEYqgNy7svyBGlqci4wobj1 ULIw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h188-20020a636cc5000000b0051f047acf17si3883559pgc.525.2023.05.12.21.24.36; Fri, 12 May 2023 21:24:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241734AbjEMDJl (ORCPT + 99 others); Fri, 12 May 2023 23:09:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57676 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229449AbjEMDJj (ORCPT ); Fri, 12 May 2023 23:09:39 -0400 Received: from dggsgout12.his.huawei.com (dggsgout12.his.huawei.com [45.249.212.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6FD794C10; Fri, 12 May 2023 20:09:37 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.30.67.153]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4QJ9bJ1p0gz4f3jHT; Sat, 13 May 2023 11:09:32 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgBn0LNs_15ksKZXJQ--.9810S3; Sat, 13 May 2023 11:09:33 +0800 (CST) Subject: Re: [PATCH 2/2] ufs: don't use the fair tag sharings To: Bart Van Assche , Christoph Hellwig Cc: Ed Tsai , axboe@kernel.dk, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org, martin.petersen@oracle.com, stanley.chu@mediatek.com, peter.wang@mediatek.com, chun-hung.wu@mediatek.com, alice.chao@mediatek.com, powen.kao@mediatek.com, naomi.chu@mediatek.com, wsd_upstream@mediatek.com, "yukuai (C)" References: <20230509065230.32552-1-ed.tsai@mediatek.com> <20230509065230.32552-3-ed.tsai@mediatek.com> <2740ee82-e35f-1cbf-f5d0-373f94eb14a5@acm.org> From: Yu Kuai Message-ID: Date: Sat, 13 May 2023 11:09:31 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <2740ee82-e35f-1cbf-f5d0-373f94eb14a5@acm.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgBn0LNs_15ksKZXJQ--.9810S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw13uFW8KF1kWry5uFykKrg_yoW8GF4kpF ZYyF15Gws8Ja4Y9a92kw4SgF1fJr95Aay7JF13Z34Ik39xArWkZr17JrW5Za45CFs5Jw10 g397XrykAFyrZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvab4IE77IF4wAFF20E14v26ryj6rWUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JM4IIrI8v6xkF7I0E8cxan2IY04v7Mxk0xIA0c2IE e2xFo4CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r4a 6rW5MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r4j6F4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyT uYvjxUFDGOUUUUU X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-CFilter-Loop: Reflected X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, 在 2023/05/13 2:12, Bart Van Assche 写道: > The fair tag sharing algorithm has a negative impact on all SCSI devices > with multiple logical units. This is because logical units are > considered active until (request timeout) seconds have elapsed after the > logical unit stopped being used (see also the blk_mq_tag_idle() call in > blk_mq_timeout_work()). UFS users are hit by this because UFS 3.0 > devices have a limited queue depth (32) and because power management > commands are submitted to a logical unit (WLUN). Hence, it happens often > that the block layer "active queue" counter is equal to 2 while only one > logical unit is being used actively (a logical unit backed by NAND > flash). The performance difference between queue depths 16 and 32 for > UFS devices is significant. We meet similiar problem before, but I think remove tag fair sharing might cause some problems, because get tag is not fair currently, for example 2 devices share 32 tag, while device a issue large amount of io concurrently, and device b only issue one io, in this case, if fair tag sharing is removed, device b can get bad io latency. By the way, I tried to propose a way to workaround this by following: 1) disable fair tag sharing untill get tag found no tag is avaiable; 2) enable fair tag sharing again if the disk donesn't faild to get tag for a period of time; Can this approch be considered? Thanks, Kuai