Received: by 2002:a05:6a10:5594:0:0:0:0 with SMTP id ee20csp166150pxb; Mon, 25 Apr 2022 07:48:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzSGlGtsverdYlQTEueKTl4fzKAvrNDOfsRwDgHND0z9MyOmpG7LOeV812dVCYwc43ForbF X-Received: by 2002:a05:6a00:1946:b0:4fe:309f:d612 with SMTP id s6-20020a056a00194600b004fe309fd612mr19315974pfk.10.1650898114588; Mon, 25 Apr 2022 07:48:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650898114; cv=none; d=google.com; s=arc-20160816; b=JevnDAdz1TvNxfP61iaJEW/cQ2803t8+YodpMwUlV4YmR9v5OK/zqNy+xhwFDY+HxM Y+rLNPg3WRSs12G5gIp9K5OLlXTwMsFyxF3Z8fFDsMnS/K8FdmzdtFG8frDFihopvtwe Lg3nzOQhxh+84yVRNuwWbqJsOWCz2rjc5A09bu18O93rblW68gQq4X4yATYiUI2O0JpQ 3v+SaaZTnVIrE+jdojwIK2XDP03wwlz+Y8pVLkw8+R0fz4yxsluv205d66AZyldCZtWv nvMVXEG2dxliOACXWLHthjOZ3wFNyj9mWQVyiOChIOCI7qh4qOc6fdAF/Hh4WDagKHkD bnJw== 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=X2lQ4uJlINlG0oj4RTnDYo3gPljFzcujmW3ty1iUr6M=; b=ahSfBktlrqyG64rp915VHf84IamjdaX1mqPkrapEtUERVfCC65KRt5x1VGgilGAKZy qFSOoCJHzcUO0MRR8iLpIFFlbJpL4NOIQyrIWwtQJtHFT/phxDlBP1dRbUnfjjKZpoQR bLnzN6E9c94Bo+d8jAsb6xeHdy3Yfyo8ZOaXucqd0nt7kwZBnoLDJuMvQdzT/ETuw1WZ 1S8sQ6je7VbuI5UujeZlakFI43OhTAS175F3vDJ5G5mLfcznxOqqcUpN8x0pyikTnN5A Mvuxs6JvljVar9BHQQdUr6sLCLlU5ckrWcZYMjbPppgci3+Lh4hc5wUmoR8nBgWn3bsB r9lA== 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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y19-20020a170902b49300b00158b60545dcsi15364948plr.207.2022.04.25.07.48.17; Mon, 25 Apr 2022 07:48:34 -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; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242132AbiDYNh2 (ORCPT + 99 others); Mon, 25 Apr 2022 09:37:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37690 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234895AbiDYNhZ (ORCPT ); Mon, 25 Apr 2022 09:37:25 -0400 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DC9F0CE3; Mon, 25 Apr 2022 06:34:20 -0700 (PDT) Received: from kwepemi500008.china.huawei.com (unknown [172.30.72.54]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Kn5Tk6SmvzCsNb; Mon, 25 Apr 2022 21:29:46 +0800 (CST) Received: from kwepemm600009.china.huawei.com (7.193.23.164) by kwepemi500008.china.huawei.com (7.221.188.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 25 Apr 2022 21:34:17 +0800 Received: from [10.174.176.73] (10.174.176.73) by kwepemm600009.china.huawei.com (7.193.23.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 25 Apr 2022 21:34:16 +0800 Subject: Re: [PATCH -next v2 2/5] block, bfq: add fake weight_counter for weight-raised queue To: Jan Kara CC: , , , , , , References: <20220416093753.3054696-1-yukuai3@huawei.com> <20220416093753.3054696-3-yukuai3@huawei.com> <20220425094856.qgkhba2klguduxot@quack3.lan> From: "yukuai (C)" Message-ID: Date: Mon, 25 Apr 2022 21:34:16 +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: <20220425094856.qgkhba2klguduxot@quack3.lan> Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.73] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600009.china.huawei.com (7.193.23.164) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS 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 ?? 2022/04/25 17:48, Jan Kara ะด??: > On Sat 16-04-22 17:37:50, Yu Kuai wrote: >> Weight-raised queue is not inserted to weights_tree, which makes it >> impossible to track how many queues have pending requests through >> weights_tree insertion and removel. This patch add fake weight_counter >> for weight-raised queue to do that. >> >> Signed-off-by: Yu Kuai > > This is a bit hacky. I was looking into a better place where to hook to > count entities in a bfq_group with requests and I think bfq_add_bfqq_busy() > and bfq_del_bfqq_busy() are ideal for this. It also makes better sense > conceptually than hooking into weights tree handling. > Hi, bfq_del_bfqq_busy() will be called when all the reqs in the bfqq are dispatched, however there might still some reqs are't completed yet. Here what we want to track is how many bfqqs have pending reqs, specifically if the bfqq have reqs are't complted. Thus I think bfq_del_bfqq_busy() is not the right place to do that. Thanks, Kuai > Other than this the rest of the series looks fine to me. > > Honza