From patchwork Wed Oct 21 01:58:09 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385288 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 4CGDDj37Nvz9sRk; Wed, 21 Oct 2020 12:58:45 +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 1kV3Oc-0005Wy-JJ; Wed, 21 Oct 2020 01:58:34 +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 1kV3Oa-0005WN-AC for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:32 +0000 Received: from mail-pl1-f199.google.com ([209.85.214.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3OZ-0002gS-UP for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:32 +0000 Received: by mail-pl1-f199.google.com with SMTP id 97so339184plb.4 for ; Tue, 20 Oct 2020 18:58:31 -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=LLI1Dko1BQ4gnk6Ze0xYLhiL5Jy9m4jAoYnnHQwUn8g=; b=qg5Miopmc6rTVvYVrB8exeWcnYymoQhn0oCraA9sb7nqwnkPOVIY6XVlAF1l84IeQl y8Gglu65x8yFoftZSt6kl0soUJagKI+vkEYOl96yI5V03rf+iqh0xQAMy0PJe30zTzu6 U3fUD1F9k8xrHrqBxAF91rgylHqaANvC1V2I4blKFXFdqM3V/H5h2H0aozAZtAlIwCCb /cDehnTbhVDPZBFhSlaoKsABSikvLCHHUw14shGITUZQxMmLw6pGk2vPklJftCw5b19k NeW+GRbxC2zQ3osNUBa1VqhmEl1GCYnocS10b+bobJdHuHOjYv3d187E+vGZNC6bt7Jv ISSg== X-Gm-Message-State: AOAM533IG0loi/OPj+n8i/Pz1zOf0JY2m+yTrz02hpueoURKSrsRXLDb 4ganlaBOB9oTqtFOGJ60orz5zrQpKNurrWs/IfmNQe0idrFTSEFJcERviQkbwAFZzv/OC6YcvXM iualmo8BxGzscxtprmo15r9/xGWcth0CibbD/YaR9Mg== X-Received: by 2002:a63:1457:: with SMTP id 23mr1035624pgu.24.1603245510410; Tue, 20 Oct 2020 18:58:30 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw5q0ofFpWhMdQAs2yD05vpbpAV05VN5vinYhNJK2TnIsbLqwZ4LfV6g10CE9AuyqQXFx5LeA== X-Received: by 2002:a63:1457:: with SMTP id 23mr1035615pgu.24.1603245510165; Tue, 20 Oct 2020 18:58:30 -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 g15sm375982pgi.89.2020.10.20.18.58.28 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:58:29 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][B][PATCH 1/3] bcache: remove member accessed from struct btree Date: Wed, 21 Oct 2020 14:58:09 +1300 Message-Id: <20201021015811.19159-2-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015811.19159-1-matthew.ruffell@canonical.com> References: <20201021015811.19159-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 (backported from commit 125d98edd11464c8e0ec9eaaba7d682d0f832686) [mruffell: minor context adjustment in bch_btree_node_get()] 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 2949b308f0b5..627a8e9c8428 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -717,14 +717,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); @@ -1020,7 +1018,6 @@ struct btree *bch_btree_node_get(struct cache_set *c, struct btree_op *op, } b->parent = parent; - b->accessed = 1; for (; i <= b->keys.nsets && b->keys.set[i].size; i++) { prefetch(b->keys.set[i].tree); @@ -1105,7 +1102,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 d211e2c25b6b..7707ada8fa95 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:58:10 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385286 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 4CGDDj1cHzz9sSG; Wed, 21 Oct 2020 12:58:45 +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 1kV3Of-0005Xj-NW; Wed, 21 Oct 2020 01:58:37 +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 1kV3Oc-0005Wc-A8 for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:34 +0000 Received: from mail-pl1-f197.google.com ([209.85.214.197]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3Ob-0002gY-Ss for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:34 +0000 Received: by mail-pl1-f197.google.com with SMTP id h20so335560plr.9 for ; Tue, 20 Oct 2020 18:58:33 -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=wnvLh7k5iVI4pYXIrS4ki6eZmjvT2JjEqIaa3BiXLJk=; b=O7JfbU6QNKtk15MfG/g4qucSVLjydsTOd4/dGr/xImTXnov1kMReR/PFOm1JQZ5ruh MMpszecCpy/Mic9XT01GVhiPJZRqkq37NpXhpE6K45Yn/UEreZcBhatfQ32Ei3MWSbe+ 1lIBhsNBWVYMI6GySshNQmpiPYdUKHuSc/+NbgzJU0zE7tPtZ9pE+ns+9OjAmBAnYLMv 3YsAStFgCEHAtPxl2bVMYfJVExR6pq9VR3grhcxzi/pDyVg9fdMMnYKRuqHtRCd5ISeo 5pCiRhqDQpYE/ZFk071HlUEuOGv+oKhTcqZJLmlLFtOuGT+gX5D+x0jh6NdWkJUhj4Bz uolg== X-Gm-Message-State: AOAM532Dv/bcvhDjFh4D38iQPBFpYSVCn2S1kSoMPaaa0AxeCt3oIXOF 0mKpry1/GACurnERm1S/cwEM8sDO2SuGTDTQGr1Cck/wdIb0I8WL66DvtN/vof1nBN+O6tlI/sD 6cetjjGVxbr0bNh3TNBpamp8GiQ1B+i8evualSu0LDg== X-Received: by 2002:a17:902:7b91:b029:d4:da66:ef6e with SMTP id w17-20020a1709027b91b02900d4da66ef6emr1051445pll.10.1603245512359; Tue, 20 Oct 2020 18:58:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxwqhJAS4F0j2/iOB0HbXQraK2wFib6jo1xA73b96z6RtaV1D+YCjrQgF0MMboEZrm9vDpsZA== X-Received: by 2002:a17:902:7b91:b029:d4:da66:ef6e with SMTP id w17-20020a1709027b91b02900d4da66ef6emr1051437pll.10.1603245512104; Tue, 20 Oct 2020 18:58:32 -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 g15sm375982pgi.89.2020.10.20.18.58.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:58:31 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][B][PATCH 2/3] bcache: reap c->btree_cache_freeable from the tail in bch_mca_scan() Date: Wed, 21 Oct 2020 14:58:10 +1300 Message-Id: <20201021015811.19159-3-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015811.19159-1-matthew.ruffell@canonical.com> References: <20201021015811.19159-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 627a8e9c8428..c38a8c9e0c8e 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -697,17 +697,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:58:11 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Ruffell X-Patchwork-Id: 1385285 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 4CGDDg60CYz9sTR; Wed, 21 Oct 2020 12:58:43 +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 1kV3Og-0005Y4-RJ; Wed, 21 Oct 2020 01:58:38 +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 1kV3Oe-0005XZ-6n for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:36 +0000 Received: from mail-pl1-f199.google.com ([209.85.214.199]) by youngberry.canonical.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1kV3Od-0002gv-Pt for kernel-team@lists.ubuntu.com; Wed, 21 Oct 2020 01:58:35 +0000 Received: by mail-pl1-f199.google.com with SMTP id y9so319797pll.18 for ; Tue, 20 Oct 2020 18:58:35 -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=ugR2M+xyFFHs11L3RtttyJRqpRfx6JfLhACJV8XoQUw=; b=ajG3G1Tt6TmRlMDair8Ki73zfzE3IQimCNGMUGhNVv2RTc/XUD3LoAdpq6ZGaoRiT7 ikJEzset8d0G99H4Gpoi1B/SARkJENv420ip9PoR1/DCNVXJOOzhAgTj2g7ncFztnXAj VfSRvBO/oJmT+qh4lYNFw/9+GWtXfQ0Z4jZnyAbzc4ERxnf4WYxjLsfy6zRX1BAEnb/d ugg8SH/lKno8+yBcmgUaP+lcU1Hzuk+g3xtW6EZHNk5M7V6fxnac8MIe5imwFDojl9PR brOUUod2+KVLNVViHmuTbZJ/fvdVzpwOZh1QZ1mGy97wx222BJtTObJKRbY5ZDKOFilH 2hnw== X-Gm-Message-State: AOAM530+V8JxXp36um3KLrxwwzZkRmGs/3T11l+YslXC+6UPC/i07An4 Kzz7Usq5grT+a8CUKPZlP3Idb9KgOuzm8rcAHV+cQGeBTPUn3qdW55/yW7Pi+wy0rpxBLujIdE0 OA3mlyWGKnETb/T3EMFvd5avdMavApjvafvzx1TU0Kw== X-Received: by 2002:a63:cd48:: with SMTP id a8mr961733pgj.83.1603245514305; Tue, 20 Oct 2020 18:58:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxbxKg7BMZVS+21iGPJKRSKMp/bYObcFTiXDnxJVPVZzCZ4w43jsBjTmCYMUNhRkQot/Nmm4g== X-Received: by 2002:a63:cd48:: with SMTP id a8mr961722pgj.83.1603245514054; Tue, 20 Oct 2020 18:58:34 -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 g15sm375982pgi.89.2020.10.20.18.58.32 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 18:58:33 -0700 (PDT) From: Matthew Ruffell To: kernel-team@lists.ubuntu.com Subject: [SRU][B][PATCH 3/3] bcache: reap from tail of c->btree_cache in bch_mca_scan() Date: Wed, 21 Oct 2020 14:58:11 +1300 Message-Id: <20201021015811.19159-4-matthew.ruffell@canonical.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20201021015811.19159-1-matthew.ruffell@canonical.com> References: <20201021015811.19159-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 c38a8c9e0c8e..83c635b14e3a 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -710,19 +710,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);