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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 71E52C3F6B0 for ; Thu, 18 Aug 2022 01:23:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234548AbiHRBXo (ORCPT ); Wed, 17 Aug 2022 21:23:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34214 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233588AbiHRBXo (ORCPT ); Wed, 17 Aug 2022 21:23:44 -0400 Received: from dggsgout11.his.huawei.com (unknown [45.249.212.51]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DE5B59FA87; Wed, 17 Aug 2022 18:23:42 -0700 (PDT) Received: from mail02.huawei.com (unknown [172.30.67.169]) by dggsgout11.his.huawei.com (SkyGuard) with ESMTP id 4M7RvN3D9nzlGFq; Thu, 18 Aug 2022 09:22:24 +0800 (CST) Received: from [10.174.176.73] (unknown [10.174.176.73]) by APP4 (Coremail) with SMTP id gCh0CgBnu_iclP1ikMHzAQ--.33655S3; Thu, 18 Aug 2022 09:23:40 +0800 (CST) Subject: Re: [PATCH v7 1/9] blk-throttle: fix that io throttle can only work for single bio To: Tejun Heo , Yu Kuai Cc: mkoutny@suse.com, axboe@kernel.dk, ming.lei@redhat.com, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, "yukuai (C)" References: <20220802140415.2960284-1-yukuai1@huaweicloud.com> <20220802140415.2960284-2-yukuai1@huaweicloud.com> <712e0f29-94ba-d3d3-ce21-cba4d6092008@huaweicloud.com> From: Yu Kuai Message-ID: <83c8b253-2ebb-5af6-8ce1-6dc3b84cf182@huaweicloud.com> Date: Thu, 18 Aug 2022 09:23:39 +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: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID: gCh0CgBnu_iclP1ikMHzAQ--.33655S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Cw1rtw43tFyxAw1xKryDKFg_yoW8Ar18pF WIq3WktF4qyF1293Z7tw129Fnayr4rZr1Yyr98Gr12y34UGr1SkrWIqF45urs3ur4kCa1j qF48tF98G3y5ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9214x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26w1j6s0DM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gc CE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0E 2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJV W8JwACjcxG0xvEwIxGrwACjI8F5VA0II8E6IAqYI8I648v4I1lFIxGxcIEc7CjxVA2Y2ka 0xkIwI1lc7I2V7IY0VAS07AlzVAYIcxG8wCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7x kEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E 67AF67kF1VAFwI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCw CI42IY6xIIjxv20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWr Zr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYx BIdaVFxhVjvjDU0xZFpf9x0JUZa9-UUUUU= X-CM-SenderInfo: 51xn3trlr6x35dzhxuhorxvhhfrp/ X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Hi, Tejun! ÔÚ 2022/08/18 1:50, Tejun Heo дµÀ: > Hello, > > On Wed, Aug 17, 2022 at 09:13:38AM +0800, Yu Kuai wrote: >>> So, as a fix for the immediate problem, I guess this might do but this feels >>> really fragile. How can we be certain that re-entering only happens because >>> of splitting? What if future core development changes that? It seems to be >>> solving the problem in the wrong place. Shouldn't we flag the bio indicating >>> that it's split when we're splitting the bio so that we only limit them for >>> iops in the first place? >> >> Splited bio is tracked in __bio_clone: > > As the word is used in commit messages and comments, the past perfect form > of the verb "split" is "split". It looks like "splitted" is used in rare > cases but dictionary says it's an archaic form. Ok, thanks for pointing it out, I'll change that in next iteration. > >> if (bio_flagged(bio_src, BIO_THROTTLED)) >> bio_set_flag(bio, BIO_THROTTLED); >> >> And currenty, the iops limit and bps limit are treated differently, >> however there are only one flag 'BIO_THROTTLED' and they can't be >> distinguished. >> >> Perhaps I can use two flags, for example BIO_IOPS_THROTTLED and >> BIO_BPS_THROTTLED, this way only iops limit can be handled and bps >> limit can be skipped for splited bio. >> >> What do you think? > > I think the code would be a lot more intuitive and less fragile if we used > two flags but the bits in the bi_flags field are a scarce resource > unfortunately. Even then, I think the right thing to do here is using two > flags. Yes, the field 'bio->bi_flags' is unsigned short, and there are only two bits left. I'll use the new sulution which will acquire a new bit. Thanks, Kuai > > Thanks. >