Received: by 2002:a5d:9c59:0:0:0:0:0 with SMTP id 25csp2213030iof; Tue, 7 Jun 2022 23:23:18 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyifk5/KpPIIMk6VBH8U0FMwlQoGePkfTdIx+zMcEZcqMfeLOlVr/5HZL1mAglLIC4TWn6N X-Received: by 2002:a17:90a:8592:b0:1dd:bab:d286 with SMTP id m18-20020a17090a859200b001dd0babd286mr36078004pjn.143.1654669398465; Tue, 07 Jun 2022 23:23:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1654669398; cv=none; d=google.com; s=arc-20160816; b=Q8o7RVBoF6wtkhYPci3IYQeFdLBx38ylZ1QN9Cc+IvHp58+IEyGNjnUpiUB3xotCPv AKvmNizxPY9AqxrWkR1VZ9XtZO2CI2PxrsNX80VlzG399X1AuoK4J/459u45L/bf9TOf 3aYRFQ8R+nsseWW8QykSD627OpNvJoNOAPhhAbyDVdnAE7NA5zdxCr7/R/EDrfDcSH9R C4s08tkbiheD/SYiF8NC+s0cJzJBh9ootj08MrE71auDYh46lfTk/CZR+sZ7kqA0myKS 2lGwJmo0zbRAR/hQMyYzGVwDfySVYYmMXUOmpOBiVeGRVoXUgPwHly+eTC8ijOUk9OgX HcHg== 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=3wZVilyrDQZzlLb3sYIgTAD0iKO1n0iFWKzxlJ1FhvU=; b=VJ7kPTixqXV1Da1z7tiAvQSNB//6uTLQ+dQCY7fWXWY36e6d8TKE+TU8B4kFc5i/6O pXBWiTelSvAeDJYm4u7cC1ZPh5SMcn+85cF5GJXO/AR82YcKYaP7Rd376LLq38GYBywi 1jeLnIL6GLBKN+sBnWt9hKmjGGBpUs4m82Vmajs2eWyqbO1tVIoJXxYN5SHiK0tV2GrG ORZFukM2inMuA1rVylisPdq+Zm8SKXG/DjDXhG6TxrKJOFFVBRzIZVCyG72QLNgnPP9M ecwnIC5i5KJgRUPH5JzMjs3Y+Lx4nSJcAXUXjrCHG97aXFbFBqP7wMVsv5XHAF/3XNBl qA0A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kCo4P1Og; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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. [23.128.96.19]) by mx.google.com with ESMTPS id x14-20020a634a0e000000b003fda62fb969si12022469pga.590.2022.06.07.23.23.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jun 2022 23:23:18 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kCo4P1Og; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 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 552CF49A291; Tue, 7 Jun 2022 22:43:49 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392388AbiFHCGD (ORCPT + 99 others); Tue, 7 Jun 2022 22:06:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1841792AbiFHAIP (ORCPT ); Tue, 7 Jun 2022 20:08:15 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6355E277F99; Tue, 7 Jun 2022 12:24:20 -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 ams.source.kernel.org (Postfix) with ESMTPS id DB029B8220B; Tue, 7 Jun 2022 19:24:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 48C95C385A2; Tue, 7 Jun 2022 19:24:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1654629857; bh=vpSNYfIzcxUQoPILJ0ylefa5STRl67qyKm19jCNCdZM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kCo4P1OgK74SPF2W2mKM5/J5k25ge9WDwlia7+IgYe1+XKvd5edbaBGz4VDt21yhO OnDG0CTdeexKceMuzQQfSCL3SOdD4tisntgMPMQFxLGoDE3NGlH032nUELQ8lvLkMx YzFT4Xr/+iCtJ07i6W4IiAn/AAxmgqBa4cWcvVg8= 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.18 841/879] bcache: remove incremental dirty sector counting for bch_sectors_dirty_init() Date: Tue, 7 Jun 2022 19:05:59 +0200 Message-Id: <20220607165027.262912637@linuxfoundation.org> X-Mailer: git-send-email 2.36.1 In-Reply-To: <20220607165002.659942637@linuxfoundation.org> References: <20220607165002.659942637@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 @@ -805,13 +805,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, @@ -827,11 +825,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; } @@ -846,24 +841,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; } @@ -907,7 +894,6 @@ static int bch_dirty_init_thread(void *a goto out; } skip_nr--; - cond_resched(); } if (p) { @@ -917,7 +903,6 @@ static int bch_dirty_init_thread(void *a p = NULL; prev_idx = cur_idx; - cond_resched(); } out: @@ -956,11 +941,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; }