Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp2374215ioo; Sat, 28 May 2022 11:39:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyprIMADJUGsNffF9o14wOcrzYuO2kLGvnLqUG5OZH1SCpfhrLln6mJX5G4x2cDtjv97e0+ X-Received: by 2002:a62:1c50:0:b0:518:89bf:8b41 with SMTP id c77-20020a621c50000000b0051889bf8b41mr35937315pfc.60.1653763185904; Sat, 28 May 2022 11:39:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653763185; cv=none; d=google.com; s=arc-20160816; b=IL2xjK0cIBF2YE5ylXMmpibbcAzpJQsNA3S2Dqi7wzKB8CXs7jcSY8oI+TGjCETXu8 Pq/lBKFafjwejv34h0TZAs0SMZmdOh1ciSZGtytKsx/3BFtYkyGi7ELAPZKuKHLVUASu /f9HTbJB/7Ccv9VTVlC6RwTDsbXvnukl7Kz1HaQFghNaPf37TltaYdsYPCK+/XNfxF4n bWIchT9dXAu4+6gOwrqkbDEuo5Cktj9tnqySyP2MclZm6uslDuxGv9CkXVlvZqjWTCM5 LOgLsNS/2D9SBdThEGikrmKVh/jjqtm83dduADuAPnLXHt+A+0aokLgmkUHMyzzegm5L zGZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=g/wa6kfUD+Qv37nzwfOpRBuWXSxXI1ZwVDPXCJM1kPg=; b=V9jSHWID33cpBVDTT4cal7qpELUyZRCrla7LaGGGNhIrXy0e0ObKSED9OBdF6js8xp usdNPcTtvTi9IOQqrBzzdBsUmRFA0ZVvcpN4M259pqWpVTxyNYOCJGlx5ZBowYj3xGyd Eefxr6GxPR6meIRB3atBscpMeEEr/HGeOluBL0NjZZ808XIDOM2kTS+TBLtuBHnSj3ro nN3zrliPpPsaab4dkDURvVXrHLf3I0RfwW4GgCD/RezYTH5gN0VogLZxU4TTpaJQZol5 KdKeIFxxIHWdH38ltBi/QzUkaSJuSMPEHr7EmFvYU+TA7i6tzCnpWz4cRqlujOD/pU8B LM3g== 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:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id d187-20020a6368c4000000b003db4cb6a71dsi10523592pgc.0.2022.05.28.11.39.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 May 2022 11:39:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7C8A427FFC; Sat, 28 May 2022 11:33:23 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233090AbiE1JhJ (ORCPT + 99 others); Sat, 28 May 2022 05:37:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbiE1Jg4 (ORCPT ); Sat, 28 May 2022 05:36:56 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6E7F165AC; Sat, 28 May 2022 02:36:52 -0700 (PDT) Received: from kwepemi500012.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4L9Gkr3lPbzjX7b; Sat, 28 May 2022 17:36:04 +0800 (CST) Received: from kwepemm600009.china.huawei.com (7.193.23.164) by kwepemi500012.china.huawei.com (7.221.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 28 May 2022 17:36:50 +0800 Received: from huawei.com (10.175.127.227) 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; Sat, 28 May 2022 17:36:49 +0800 From: Yu Kuai To: , , CC: , , , , Subject: [PATCH -next v7 0/3] support concurrent sync io for bfq on a specail occasion Date: Sat, 28 May 2022 17:50:17 +0800 Message-ID: <20220528095020.186970-1-yukuai3@huawei.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=US-ASCII X-Originating-IP: [10.175.127.227] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600009.china.huawei.com (7.193.23.164) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Changes in v7: - fix mismatch bfq_inc/del_busy_queues() and bfqq_add/del_bfqq_busy(), also retest this patchset on v5.18 to make sure functionality is correct. - move the updating of 'bfqd->busy_queues' into new apis Changes in v6: - add reviewed-by tag for patch 1 Changes in v5: - rename bfq_add_busy_queues() to bfq_inc_busy_queues() in patch 1 - fix wrong definition in patch 1 - fix spelling mistake in patch 2: leaset -> least - update comments in patch 3 - add reviewed-by tag in patch 2,3 Changes in v4: - split bfq_update_busy_queues() to bfq_add/dec_busy_queues(), suggested by Jan Kara. - remove unused 'in_groups_with_pending_reqs', Changes in v3: - remove the cleanup patch that is irrelevant now(I'll post it separately). - instead of hacking wr queues and using weights tree insertion/removal, using bfq_add/del_bfqq_busy() to count the number of groups (suggested by Jan Kara). Changes in v2: - Use a different approch to count root group, which is much simple. Currently, bfq can't handle sync io concurrently as long as they are not issued from root group. This is because 'bfqd->num_groups_with_pending_reqs > 0' is always true in bfq_asymmetric_scenario(). The way that bfqg is counted into 'num_groups_with_pending_reqs': Before this patchset: 1) root group will never be counted. 2) Count if bfqg or it's child bfqgs have pending requests. 3) Don't count if bfqg and it's child bfqgs complete all the requests. After this patchset: 1) root group is counted. 2) Count if bfqg have at least one bfqq that is marked busy. 3) Don't count if bfqg doesn't have any busy bfqqs. The main reason to use busy state of bfqq instead of 'pending requests' is that bfqq can stay busy after dispatching the last request if idling is needed for service guarantees. With the above changes, concurrent sync io can be supported if only one group is activated. fio test script(startdelay is used to avoid queue merging): [global] filename=/dev/sda allow_mounted_write=0 ioengine=psync direct=1 ioscheduler=bfq offset_increment=10g group_reporting rw=randwrite bs=4k [test1] numjobs=1 [test2] startdelay=1 numjobs=1 [test3] startdelay=2 numjobs=1 [test4] startdelay=3 numjobs=1 [test5] startdelay=4 numjobs=1 [test6] startdelay=5 numjobs=1 [test7] startdelay=6 numjobs=1 [test8] startdelay=7 numjobs=1 test result: running fio on root cgroup v5.18: 112 Mib/s v5.18-patched: 112 Mib/s running fio on non-root cgroup v5.18: 51.2 Mib/s v5.18-patched: 112 Mib/s Note that I also test null_blk with "irqmode=2 completion_nsec=100000000(100ms) hw_queue_depth=1", and tests show that service guarantees are still preserved. Previous versions: RFC: https://lore.kernel.org/all/20211127101132.486806-1-yukuai3@huawei.com/ v1: https://lore.kernel.org/all/20220305091205.4188398-1-yukuai3@huawei.com/ v2: https://lore.kernel.org/all/20220416093753.3054696-1-yukuai3@huawei.com/ v3: https://lore.kernel.org/all/20220427124722.48465-1-yukuai3@huawei.com/ v4: https://lore.kernel.org/all/20220428111907.3635820-1-yukuai3@huawei.com/ v5: https://lore.kernel.org/all/20220428120837.3737765-1-yukuai3@huawei.com/ v6: https://lore.kernel.org/all/20220523131818.2798712-1-yukuai3@huawei.com/ Yu Kuai (3): block, bfq: record how many queues are busy in bfq_group block, bfq: refactor the counting of 'num_groups_with_pending_reqs' block, bfq: do not idle if only one group is activated block/bfq-cgroup.c | 1 + block/bfq-iosched.c | 48 +++----------------------------------- block/bfq-iosched.h | 57 +++++++-------------------------------------- block/bfq-wf2q.c | 41 ++++++++++++++++++++------------ 4 files changed, 39 insertions(+), 108 deletions(-) -- 2.31.1