Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2252917iof; Wed, 8 Jun 2022 00:33:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJznae7y6JIZirXMiVaSOTbIdMjNejyAfT0Iqyw/t0vOlKEidGSetL0opTBLn3V2aQ0ykf1u X-Received: by 2002:a65:6c07:0:b0:3f2:5efb:6c7 with SMTP id y7-20020a656c07000000b003f25efb06c7mr29164341pgu.496.1654673623475; Wed, 08 Jun 2022 00:33:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654673623; cv=none; d=google.com; s=arc-20160816; b=F5C6lkZ+iIQqpmZonbyc6NaFcDdZMRFI1r41eI7nP7SfGeU/h9xSH+keED+vIgJSm2 SAjLhhfl2rketq7pQoVcj0dc9Mprs9/+OuInuawsW1DvIRMgxn6BR3lHp02wP4EPbEVW bfzQ+cfSk8LGRp880T688SBvwRjqWz50QA02RxzoVx+GH5wvEdCXUUfnkDuVI0MILrLE LgQ/LAouUyc5StWCheFntLQpV/QgiGJz0kP2tCKICuIoYsm5sgJXandhQGNtl5bo9lPu yobnEQl7lQq4VP5uxamfG+oDDNPV0N55uOqEsPgDa4WbxA1K5wxE88Dmlh/724ezaZ+G SpjA== 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 :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=XNJ2Tw0aTJ2a1rWC6CPN6zte9naR/X5oIAOZ6CHkGdc=; b=YJj6JooWUh/TH1tRaANRaEXFNcuO+CXqiuF4iHUrLkwL+6rz5wdAGB4Zuf/DskN8cu KpOuqtYUPA+wUC/RGhWTNV44NTdGZ/4UPWZm3CapG/FKUyklCgk7jHlkYelJbA81/hdF hD5Qf+BZz4hyG1ovMhoIhc0+Vv4TF1iLHXppKOuFcz+5UFE2xAvnGlQFcgaiS5hnBpmG /SRuECutCu1VrLh2el4uKXrSmHzILtz0YXE0eUC5PAkW9oGO5MmM58LeiG4E6fV0Ceug YpV1eFrR4ShyB2Y2eahqQrphCztU+91uaCpIQ9Sm/12NzEzAjaAWy2Pc4slO/f1JN/UI 5jeg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="RiI/2K2N"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id m2-20020a655642000000b003f5d8756675si29775208pgs.371.2022.06.08.00.33.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 00:33:43 -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; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="RiI/2K2N"; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 96D03152B8F; Wed, 8 Jun 2022 00:06:17 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1383718AbiFGWHy (ORCPT + 99 others); Tue, 7 Jun 2022 18:07:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1377448AbiFGU7t (ORCPT ); Tue, 7 Jun 2022 16:59:49 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 373D320C278; Tue, 7 Jun 2022 11:45:00 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 29C0561295; Tue, 7 Jun 2022 18:45:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E3C1C385A5; Tue, 7 Jun 2022 18:44:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654627499; bh=wEN67JUF7h90gFRJYEPgOYbXPQQrDcNRic4aTK3LJmM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RiI/2K2NALua44dQYWsRful3aWEBubsA4t3cBTpxg5/CYOIgFuJVYt1mIVkRbaSQO 62SAo2ZTrtD/b9glQkMOhiPFkdN1WZmx/83evsd7UzAmszhuBZFzR7GBiXFg9KQACy fWUsoctoJ9wj59qYe3IxpojNEmHDt4yfhxaeo15g= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Coly Li , Jens Axboe Subject: [PATCH 5.17 735/772] bcache: remove incremental dirty sector counting for bch_sectors_dirty_init() Date: Tue, 7 Jun 2022 19:05:27 +0200 Message-Id: <20220607165010.696584347@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607164948.980838585@linuxfoundation.org> References: <20220607164948.980838585@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 From: Coly Li commit 80db4e4707e78cb22287da7d058d7274bd4cb370 upstream. After making bch_sectors_dirty_init() being multithreaded, the existing incremental dirty sector counting in bch_root_node_dirty_init() doesn't release btree occupation after iterating 500000 (INIT_KEYS_EACH_TIME) bkeys. Because a read lock is added on btree root node to prevent the btree to be split during the dirty sectors counting, other I/O requester has no chance to gain the write lock even restart bcache_btree(). That is to say, the incremental dirty sectors counting is incompatible to the multhreaded bch_sectors_dirty_init(). We have to choose one and drop another one. In my testing, with 512 bytes random writes, I generate 1.2T dirty data and a btree with 400K nodes. With single thread and incremental dirty sectors counting, it takes 30+ minites to register the backing device. And with multithreaded dirty sectors counting, the backing device registration can be accomplished within 2 minutes. The 30+ minutes V.S. 2- minutes difference makes me decide to keep multithreaded bch_sectors_dirty_init() and drop the incremental dirty sectors counting. This is what this patch does. But INIT_KEYS_EACH_TIME is kept, in sectors_dirty_init_fn() the CPU will be released by cond_resched() after every INIT_KEYS_EACH_TIME keys iterated. This is to avoid the watchdog reports a bogus soft lockup warning. Fixes: b144e45fc576 ("bcache: make bch_sectors_dirty_init() to be multithreaded") Signed-off-by: Coly Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220524102336.10684-4-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman --- drivers/md/bcache/writeback.c | 39 ++++++++++++--------------------------- 1 file changed, 12 insertions(+), 27 deletions(-) --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -802,13 +802,11 @@ static int bch_writeback_thread(void *ar /* Init */ #define INIT_KEYS_EACH_TIME 500000 -#define INIT_KEYS_SLEEP_MS 100 struct sectors_dirty_init { struct btree_op op; unsigned int inode; size_t count; - struct bkey start; }; static int sectors_dirty_init_fn(struct btree_op *_op, struct btree *b, @@ -824,11 +822,8 @@ static int sectors_dirty_init_fn(struct KEY_START(k), KEY_SIZE(k)); op->count++; - if (atomic_read(&b->c->search_inflight) && - !(op->count % INIT_KEYS_EACH_TIME)) { - bkey_copy_key(&op->start, k); - return -EAGAIN; - } + if (!(op->count % INIT_KEYS_EACH_TIME)) + cond_resched(); return MAP_CONTINUE; } @@ -843,24 +838,16 @@ static int bch_root_node_dirty_init(stru bch_btree_op_init(&op.op, -1); op.inode = d->id; op.count = 0; - op.start = KEY(op.inode, 0, 0); - do { - ret = bcache_btree(map_keys_recurse, - k, - c->root, - &op.op, - &op.start, - sectors_dirty_init_fn, - 0); - if (ret == -EAGAIN) - schedule_timeout_interruptible( - msecs_to_jiffies(INIT_KEYS_SLEEP_MS)); - else if (ret < 0) { - pr_warn("sectors dirty init failed, ret=%d!\n", ret); - break; - } - } while (ret == -EAGAIN); + ret = bcache_btree(map_keys_recurse, + k, + c->root, + &op.op, + &KEY(op.inode, 0, 0), + sectors_dirty_init_fn, + 0); + if (ret < 0) + pr_warn("sectors dirty init failed, ret=%d!\n", ret); return ret; } @@ -904,7 +891,6 @@ static int bch_dirty_init_thread(void *a goto out; } skip_nr--; - cond_resched(); } if (p) { @@ -914,7 +900,6 @@ static int bch_dirty_init_thread(void *a p = NULL; prev_idx = cur_idx; - cond_resched(); } out: @@ -953,11 +938,11 @@ void bch_sectors_dirty_init(struct bcach bch_btree_op_init(&op.op, -1); op.inode = d->id; op.count = 0; - op.start = KEY(op.inode, 0, 0); for_each_key_filter(&c->root->keys, k, &iter, bch_ptr_invalid) sectors_dirty_init_fn(&op.op, c->root, k); + rw_unlock(0, c->root); return; }