From: Coly Li <colyli@suse.de>
To: axboe@kernel.dk
Cc: linux-bcache@vger.kernel.org, linux-block@vger.kernel.org,
Coly Li <colyli@suse.de>
Subject: [PATCH 2/3] bcache: Revert "bcache: shrink btree node cache after bch_btree_check()"
Date: Thu, 13 Feb 2020 22:12:06 +0800 [thread overview]
Message-ID: <20200213141207.77219-3-colyli@suse.de> (raw)
In-Reply-To: <20200213141207.77219-1-colyli@suse.de>
This reverts commit 1df3877ff6a4810054237c3259d900ded4468969.
In my testing, sometimes even all the cached btree nodes are freed,
creating gc and allocator kernel threads may still fail. Finally it
turns out that kthread_run() may fail if there is pending signal for
current task. And the pending signal is sent from OOM killer which
is triggered by memory consuption in bch_btree_check().
Therefore explicitly shrinking bcache btree node here does not help,
and after the shrinker callback is improved, as well as pending signals
are ignored before creating kernel threads, now such operation is
unncessary anymore.
This patch reverts the commit 1df3877ff6a4 ("bcache: shrink btree node
cache after bch_btree_check()") because we have better improvement now.
Signed-off-by: Coly Li <colyli@suse.de>
---
drivers/md/bcache/super.c | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 2749daf09724..0c3c5419c52b 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1917,23 +1917,6 @@ static int run_cache_set(struct cache_set *c)
if (bch_btree_check(c))
goto err;
- /*
- * bch_btree_check() may occupy too much system memory which
- * has negative effects to user space application (e.g. data
- * base) performance. Shrink the mca cache memory proactively
- * here to avoid competing memory with user space workloads..
- */
- if (!c->shrinker_disabled) {
- struct shrink_control sc;
-
- sc.gfp_mask = GFP_KERNEL;
- sc.nr_to_scan = c->btree_cache_used * c->btree_pages;
- /* first run to clear b->accessed tag */
- c->shrink.scan_objects(&c->shrink, &sc);
- /* second run to reap non-accessed nodes */
- c->shrink.scan_objects(&c->shrink, &sc);
- }
-
bch_journal_mark(c, &journal);
bch_initial_gc_finish(c);
pr_debug("btree_check() done");
--
2.16.4
next prev parent reply other threads:[~2020-02-13 14:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 14:12 [PATCH 0/3] bcache patches for Linux v5.6-rc2 Coly Li
2020-02-13 14:12 ` [PATCH 1/3] bcache: ignore pending signals when creating gc and allocator thread Coly Li
2020-02-19 16:32 ` Christoph Hellwig
2020-02-20 13:20 ` Coly Li
2020-02-20 16:38 ` Christoph Hellwig
2020-02-20 16:47 ` Coly Li
2020-02-13 14:12 ` Coly Li [this message]
2020-02-13 14:12 ` [PATCH 3/3] bcache: remove macro nr_to_fifo_front() Coly Li
2020-02-13 15:54 ` [PATCH 0/3] bcache patches for Linux v5.6-rc2 Jens Axboe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200213141207.77219-3-colyli@suse.de \
--to=colyli@suse.de \
--cc=axboe@kernel.dk \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.