From patchwork Wed Oct 21 01:59:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385290 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CGDFZ5Xkcz9sTD; Wed, 21 Oct 2020 12:59:30 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kV3PS-0005jH-Fr; Wed, 21 Oct 2020 01:59:26 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PO-0005iR-Nj for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:22 +0000 Received: from mail-pg1-f198.google.com ([209.85.215.198]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PO-0002kC-C7 for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:22 +0000 Received: by mail-pg1-f198.google.com with SMTP id j10so373603pgc.6 for ; Tue, 20 Oct 2020 18:59:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=hQXLkeo1f4E69weKQHQ8kVJR72RCIumxlAmyQBWymBc=; b=nWYjKfcbCu2a6A2TWebIAmp6/Lwm9OJCxwE25cg92OdrE+ToQabH5rbD5mdM6RMd1B Nnl5a3lhKqhqJAmIpXM7BJkzXNJnmHxuI41zNPwwf6QSvElSHlD35f3QIkSjP4elqZdF iTfKonAXL188CtilLUAS7Sbl2FhfnSsGnVt9gQ2KeqfckUVC/X8mHZqPDfDKgYrMo3gS +zJ//C/iWuXIlFnHOhsLM1ut7yfuh/NZ8m77mY76oUJ3PBsfp+89ymCeijqvT80hCpo1 3YztD/5ZGcrvgMd0v0+wkeD5zNnEtrMm/aqG9sTpEsWPql6LS33fPEuntcGuU1pKUE1L 36KQ== X-Gm-Message-State: AOAM531xVY9pHFeZckyYRfoAAevlZ7Ksi9FQJor7PqrgRMGubWzbdiq0 MpOz9RdMWV6zYD22cJ1fJhkKnLoFOe3djDP+fN7ONGRebC94PuWrPXAjqfZp5bieSPzQHnTegs9 JTJvoCozIETqfA3R2tDv34M/pWAb+x9bfps9CHFIXXA== X-Received: by 2002:a63:1466:: with SMTP id 38mr1043816pgu.150.1603245560895; Tue, 20 Oct 2020 18:59:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLZOr9WtFrJbiyjyEwC2e1HN6ZbKVLEEIkSnO3mJd6EfPmZrLNNPDr+NgCDskvhgnE0CyqKA== X-Received: by 2002:a63:1466:: with SMTP id 38mr1043801pgu.150.1603245560539; Tue, 20 Oct 2020 18:59:20 -0700 (PDT) Received: from localhost.localdomain (222-152-178-139-fibre.sparkbb.co.nz. [222.152.178.139]) by smtp.gmail.com with ESMTPSA id j23sm377339pgm.76.2020.10.20.18.59.18 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:59:20 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][F][PATCH 1/3] bcache: remove member accessed from struct btree Date: Wed, 21 Oct 2020 14:59:00 +1300 Message-Id: <20201021015902.19223-2-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015902.19223-1-matthew.ruffell@canonical.com> References: <20201021015902.19223-1-matthew.ruffell@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Coly Li BugLink: https://bugs.launchpad.net/bugs/1898786 The member 'accessed' of struct btree is used in bch_mca_scan() when shrinking btree node caches. The original idea is, if b->accessed is set, clean it and look at next btree node cache from c->btree_cache list, and only shrink the caches whose b->accessed is cleaned. Then only cold btree node cache will be shrunk. But when I/O pressure is high, it is very probably that b->accessed of a btree node cache will be set again in bch_btree_node_get() before bch_mca_scan() selects it again. Then there is no chance for bch_mca_scan() to shrink enough memory back to slub or slab system. This patch removes member accessed from struct btree, then once a btree node ache is selected, it will be immediately shunk. By this change, bch_mca_scan() may release btree node cahce more efficiently. Signed-off-by: Coly Li Signed-off-by: Jens Axboe (cherry picked from commit 125d98edd11464c8e0ec9eaaba7d682d0f832686) Signed-off-by: Matthew Ruffell --- drivers/md/bcache/btree.c | 8 ++------ drivers/md/bcache/btree.h | 2 -- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c index 8d06105fc9ff..050f1c333d4e 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -749,14 +749,12 @@ static unsigned long bch_mca_scan(struct shrinker *shrink, b = list_first_entry(&c->btree_cache, struct btree, list); list_rotate_left(&c->btree_cache); - if (!b->accessed && - !mca_reap(b, 0, false)) { + if (!mca_reap(b, 0, false)) { mca_bucket_free(b); mca_data_free(b); rw_unlock(true, b); freed++; - } else - b->accessed = 0; + } } out: mutex_unlock(&c->bucket_lock); @@ -1064,7 +1062,6 @@ struct btree *bch_btree_node_get(struct cache_set *c, struct btree_op *op, BUG_ON(!b->written); b->parent = parent; - b->accessed = 1; for (; i <= b->keys.nsets && b->keys.set[i].size; i++) { prefetch(b->keys.set[i].tree); @@ -1155,7 +1152,6 @@ struct btree *__bch_btree_node_alloc(struct cache_set *c, struct btree_op *op, goto retry; } - b->accessed = 1; b->parent = parent; bch_bset_init_next(&b->keys, b->keys.set->data, bset_magic(&b->c->sb)); diff --git a/drivers/md/bcache/btree.h b/drivers/md/bcache/btree.h index 76cfd121a486..f4dcca449391 100644 --- a/drivers/md/bcache/btree.h +++ b/drivers/md/bcache/btree.h @@ -121,8 +121,6 @@ struct btree { /* Key/pointer for this btree node */ BKEY_PADDED(key); - /* Single bit - set when accessed, cleared by shrinker */ - unsigned long accessed; unsigned long seq; struct rw_semaphore lock; struct cache_set *c; From patchwork Wed Oct 21 01:59:01 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385292 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CGDFb3j2Mz9sTR; Wed, 21 Oct 2020 12:59:31 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kV3PT-0005k3-Kq; Wed, 21 Oct 2020 01:59:27 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PQ-0005j2-Lo for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:24 +0000 Received: from mail-pf1-f197.google.com ([209.85.210.197]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PQ-0002kJ-9g for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:24 +0000 Received: by mail-pf1-f197.google.com with SMTP id g14so283399pfb.8 for ; Tue, 20 Oct 2020 18:59:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=IbpKqB8YVvPE65y2lkTIZxYUzdeHMN094ZAeZkandS8=; b=BoyFi3K8jKyEbjIeXer+e048BmjSOoplUI9dUJf3jqST9SE0D4d6iWDabbJXJmEH1w MziCQobSA/JwqjFpsOLA7HWJNORwI8M2RspA3T2rdwenyoJCRBmmn6dGsP4aCISTOF+h Jq000WziUpzqEyoZcPoIh8zVsbgEb2opUItz2W1KVup6e062rz+aDEcrfTpaAESfMa5p gS+8HqndFL4WlsusvsONDv455NMc1K5VT0wAaj1UvX/frBaF5bwQ73crOsIrabx6PwWC gw5J2FfGGteatvTAxDOIjwvlXxgZJXQO2H/097ukbegUs5iYuBIC9mE/5LMFPK7Qe5vv ZMVw== X-Gm-Message-State: AOAM531gZzsUOZbYn46VoxOyJew5P+Zvx2fUqbUfvav/E180ivABoGs4 YEOYLTVe/7WQFq4FE0AHTVnK2F0/t2wTavip+9hvU2M7P34275XYf8nwFAS0O3d9CrK4ul/Cmku GGZad+yWk1EkPnGiO1R+P07lTzqWga41dY5Sxl2A+8Q== X-Received: by 2002:a63:4b1c:: with SMTP id y28mr1023973pga.382.1603245562806; Tue, 20 Oct 2020 18:59:22 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyWcRwsgr3gyODJG5imXsw/ZSgLRXNCdhHDEXcCamaZXU8XZTcLa2JFlryKxgKqlL9jvNLeSw== X-Received: by 2002:a63:4b1c:: with SMTP id y28mr1023960pga.382.1603245562537; Tue, 20 Oct 2020 18:59:22 -0700 (PDT) Received: from localhost.localdomain (222-152-178-139-fibre.sparkbb.co.nz. [222.152.178.139]) by smtp.gmail.com with ESMTPSA id j23sm377339pgm.76.2020.10.20.18.59.21 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:59:22 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][F][PATCH 2/3] bcache: reap c->btree_cache_freeable from the tail in bch_mca_scan() Date: Wed, 21 Oct 2020 14:59:01 +1300 Message-Id: <20201021015902.19223-3-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015902.19223-1-matthew.ruffell@canonical.com> References: <20201021015902.19223-1-matthew.ruffell@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Coly Li BugLink: https://bugs.launchpad.net/bugs/1898786 In order to skip the most recently freed btree node cahce, currently in bch_mca_scan() the first 3 caches in c->btree_cache_freeable list are skipped when shrinking bcache node caches in bch_mca_scan(). The related code in bch_mca_scan() is, 737 list_for_each_entry_safe(b, t, &c->btree_cache_freeable, list) { 738 if (nr <= 0) 739 goto out; 740 741 if (++i > 3 && 742 !mca_reap(b, 0, false)) { lines free cache memory 746 } 747 nr--; 748 } The problem is, if virtual memory code calls bch_mca_scan() and the calculated 'nr' is 1 or 2, then in the above loop, nothing will be shunk. In such case, if slub/slab manager calls bch_mca_scan() for many times with small scan number, it does not help to shrink cache memory and just wasts CPU cycles. This patch just selects btree node caches from tail of the c->btree_cache_freeable list, then the newly freed host cache can still be allocated by mca_alloc(), and at least 1 node can be shunk. Signed-off-by: Coly Li Signed-off-by: Jens Axboe (cherry picked from commit d5c9c470b01177e4d90cdbf178b8c7f37f5b8795) Signed-off-by: Matthew Ruffell --- drivers/md/bcache/btree.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c index 050f1c333d4e..c9b87a6e1c2e 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -729,17 +729,17 @@ static unsigned long bch_mca_scan(struct shrinker *shrink, i = 0; btree_cache_used = c->btree_cache_used; - list_for_each_entry_safe(b, t, &c->btree_cache_freeable, list) { + list_for_each_entry_safe_reverse(b, t, &c->btree_cache_freeable, list) { if (nr <= 0) goto out; - if (++i > 3 && - !mca_reap(b, 0, false)) { + if (!mca_reap(b, 0, false)) { mca_data_free(b); rw_unlock(true, b); freed++; } nr--; + i++; } for (; (nr--) && i < btree_cache_used; i++) { From patchwork Wed Oct 21 01:59:02 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385291 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.ubuntu.com (client-ip=91.189.94.19; helo=huckleberry.canonical.com; envelope-from=kernel-team-bounces@lists.ubuntu.com; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=canonical.com Received: from huckleberry.canonical.com (huckleberry.canonical.com [91.189.94.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CGDFb1KhJz9sTK; Wed, 21 Oct 2020 12:59:30 +1100 (AEDT) Received: from localhost ([127.0.0.1] helo=huckleberry.canonical.com) by huckleberry.canonical.com with esmtp (Exim 4.86_2) (envelope-from ) id 1kV3PT-0005kH-T1; Wed, 21 Oct 2020 01:59:27 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by huckleberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PS-0005jV-PJ for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:26 +0000 Received: from mail-pg1-f199.google.com ([209.85.215.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3PS-0002kX-Bl for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:59:26 +0000 Received: by mail-pg1-f199.google.com with SMTP id t195so364124pgb.15 for ; Tue, 20 Oct 2020 18:59:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dWs9CtYPl6AW1E31Zor9N3kX+U97xAZ4J09YYgWIbYM=; b=lXrIQ52x8AoFd1WZutUSWEi9H3H+3SK+qf6Fty3A/bTrxkW1RVfa6E0eUTLTmX4jvA 84hHA/uXqbaSszk0SCeM81zwwzphTlvzaPihXHB3uiCNMR7i8L+Hl1AKV1YrL+8Yed0I oRcXifQtipnBaVvE93k+nrq2ROATDoxDk9ndbEhWuF9uc1AuWQQywYj6cPI19wD91TNj 6RKpoaYSqMNHqmCDojC+HHpMliHz2Aoj8WE3oSYkqXVrwAjRqChAxzoWpMNl6PeqsgNN ylkAH1lDqJclNMDXUoQ+2aokwa7Pjy1t6kY7PXVIGMDqCPGRcvr2svbQKX/BX6sVbdhj Pi0g== X-Gm-Message-State: AOAM531FgrhY7zO093VbbKzqSisuNCU3HLcpGI5TE3BvHt7jvwX8tCjf sjqQS4j9EvnxSl1PbGU4eeX7xKRyOK7XrcPVqSkNj4S4Y+PGtwhroG6YCfUSrhjH3DY0nvgzKCi JtBHa6QHSGu3AhmUuyRIGvzBUy2OvUi8HcOWrGUXdOA== X-Received: by 2002:a63:2f81:: with SMTP id v123mr1019998pgv.6.1603245564804; Tue, 20 Oct 2020 18:59:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxdLlCssbnQuHn62uRlIHNfI+9HCu1TXrEu/AaHb05HwNbLo5gilUp9amJjCkjC70EGKUiVFA== X-Received: by 2002:a63:2f81:: with SMTP id v123mr1019983pgv.6.1603245564536; Tue, 20 Oct 2020 18:59:24 -0700 (PDT) Received: from localhost.localdomain (222-152-178-139-fibre.sparkbb.co.nz. [222.152.178.139]) by smtp.gmail.com with ESMTPSA id j23sm377339pgm.76.2020.10.20.18.59.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:59:24 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][F][PATCH 3/3] bcache: reap from tail of c->btree_cache in bch_mca_scan() Date: Wed, 21 Oct 2020 14:59:02 +1300 Message-Id: <20201021015902.19223-4-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015902.19223-1-matthew.ruffell@canonical.com> References: <20201021015902.19223-1-matthew.ruffell@canonical.com> MIME-Version: 1.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kernel-team-bounces@lists.ubuntu.com Sender: "kernel-team" From: Coly Li BugLink: https://bugs.launchpad.net/bugs/1898786 When shrink btree node cache from c->btree_cache in bch_mca_scan(), no matter the selected node is reaped or not, it will be rotated from the head to the tail of c->btree_cache list. But in bcache journal code, when flushing the btree nodes with oldest journal entry, btree nodes are iterated and slected from the tail of c->btree_cache list in btree_flush_write(). The list_rotate_left() in bch_mca_scan() will make btree_flush_write() iterate more nodes in c->btree_list in reverse order. This patch just reaps the selected btree node cache, and not move it from the head to the tail of c->btree_cache list. Then bch_mca_scan() will not mess up c->btree_cache list to btree_flush_write(). Signed-off-by: Coly Li Signed-off-by: Jens Axboe (cherry picked from commit e3de04469a49ee09c89e80bf821508df458ccee6) Signed-off-by: Matthew Ruffell --- drivers/md/bcache/btree.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c index c9b87a6e1c2e..61d504b3e323 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -742,19 +742,19 @@ static unsigned long bch_mca_scan(struct shrinker *shrink, i++; } - for (; (nr--) && i < btree_cache_used; i++) { - if (list_empty(&c->btree_cache)) + list_for_each_entry_safe_reverse(b, t, &c->btree_cache, list) { + if (nr <= 0 || i >= btree_cache_used) goto out; - b = list_first_entry(&c->btree_cache, struct btree, list); - list_rotate_left(&c->btree_cache); - if (!mca_reap(b, 0, false)) { mca_bucket_free(b); mca_data_free(b); rw_unlock(true, b); freed++; } + + nr--; + i++; } out: mutex_unlock(&c->bucket_lock);