* [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() [not found] <20191211152831.23507-1-sashal@kernel.org> @ 2019-12-11 15:28 ` Sasha Levin 2019-12-12 3:48 ` John Stoffel 0 siblings, 1 reply; 4+ messages in thread From: Sasha Levin @ 2019-12-11 15:28 UTC (permalink / raw) To: linux-kernel, stable Cc: Coly Li, Jens Axboe, Sasha Levin, linux-bcache, linux-raid From: Coly Li <colyli@suse.de> [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ] In bch_mca_scan(), the number of shrinking btree node is calculated by code like this, unsigned long nr = sc->nr_to_scan; nr /= c->btree_pages; nr = min_t(unsigned long, nr, mca_can_free(c)); variable sc->nr_to_scan is number of objects (here is bcache B+tree nodes' number) to shrink, and pointer variable sc is sent from memory management code as parametr of a callback. If sc->nr_to_scan is smaller than c->btree_pages, after the above calculation, variable 'nr' will be 0 and nothing will be shrunk. It is frequeently observed that only 1 or 2 is set to sc->nr_to_scan and make nr to be zero. Then bch_mca_scan() will do nothing more then acquiring and releasing mutex c->bucket_lock. This patch checkes whether nr is 0 after the above calculation, if 0 is the result then set 1 to variable 'n'. Then at least bch_mca_scan() will try to shrink a single B+tree node. Signed-off-by: Coly Li <colyli@suse.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> --- drivers/md/bcache/btree.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/md/bcache/btree.c b/drivers/md/bcache/btree.c index 9406326216f17..96a6583e7b522 100644 --- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -685,6 +685,8 @@ static unsigned long bch_mca_scan(struct shrinker *shrink, * IO can always make forward progress: */ nr /= c->btree_pages; + if (nr == 0) + nr = 1; nr = min_t(unsigned long, nr, mca_can_free(c)); i = 0; -- 2.20.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() 2019-12-11 15:28 ` [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() Sasha Levin @ 2019-12-12 3:48 ` John Stoffel 2019-12-12 3:52 ` Coly Li 0 siblings, 1 reply; 4+ messages in thread From: John Stoffel @ 2019-12-12 3:48 UTC (permalink / raw) To: Sasha Levin Cc: linux-kernel, stable, Coly Li, Jens Axboe, linux-bcache, linux-raid >>>>> "Sasha" == Sasha Levin <sashal@kernel.org> writes: Sasha> From: Coly Li <colyli@suse.de> Sasha> [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ] Sasha> In bch_mca_scan(), the number of shrinking btree node is calculated Sasha> by code like this, Sasha> unsigned long nr = sc->nr_to_scan; Sasha> nr /= c->btree_pages; Sasha> nr = min_t(unsigned long, nr, mca_can_free(c)); Sasha> variable sc->nr_to_scan is number of objects (here is bcache B+tree Sasha> nodes' number) to shrink, and pointer variable sc is sent from memory Sasha> management code as parametr of a callback. Sasha> If sc->nr_to_scan is smaller than c->btree_pages, after the above Sasha> calculation, variable 'nr' will be 0 and nothing will be shrunk. It is Sasha> frequeently observed that only 1 or 2 is set to sc->nr_to_scan and make Sasha> nr to be zero. Then bch_mca_scan() will do nothing more then acquiring Sasha> and releasing mutex c->bucket_lock. Sasha> This patch checkes whether nr is 0 after the above calculation, if 0 Sasha> is the result then set 1 to variable 'n'. Then at least bch_mca_scan() Sasha> will try to shrink a single B+tree node. Sasha> nr /= c->btree_pages; Sasha> + if (nr == 0) Sasha> + nr = 1; Wouldn't it be even more clear with: nr /= c->bree_pages || 1; instead? John ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() 2019-12-12 3:48 ` John Stoffel @ 2019-12-12 3:52 ` Coly Li 2019-12-12 4:00 ` John Stoffel 0 siblings, 1 reply; 4+ messages in thread From: Coly Li @ 2019-12-12 3:52 UTC (permalink / raw) To: John Stoffel, Sasha Levin Cc: linux-kernel, stable, Jens Axboe, linux-bcache, linux-raid On 2019/12/12 11:48 上午, John Stoffel wrote: >>>>>> "Sasha" == Sasha Levin <sashal@kernel.org> writes: > > Sasha> From: Coly Li <colyli@suse.de> > Sasha> [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ] > > Sasha> In bch_mca_scan(), the number of shrinking btree node is calculated > Sasha> by code like this, > Sasha> unsigned long nr = sc->nr_to_scan; > > Sasha> nr /= c->btree_pages; > Sasha> nr = min_t(unsigned long, nr, mca_can_free(c)); > Sasha> variable sc->nr_to_scan is number of objects (here is bcache B+tree > Sasha> nodes' number) to shrink, and pointer variable sc is sent from memory > Sasha> management code as parametr of a callback. > > Sasha> If sc->nr_to_scan is smaller than c->btree_pages, after the above > Sasha> calculation, variable 'nr' will be 0 and nothing will be shrunk. It is > Sasha> frequeently observed that only 1 or 2 is set to sc->nr_to_scan and make > Sasha> nr to be zero. Then bch_mca_scan() will do nothing more then acquiring > Sasha> and releasing mutex c->bucket_lock. > > Sasha> This patch checkes whether nr is 0 after the above calculation, if 0 > Sasha> is the result then set 1 to variable 'n'. Then at least bch_mca_scan() > Sasha> will try to shrink a single B+tree node. > > Sasha> nr /= c->btree_pages; > Sasha> + if (nr == 0) > Sasha> + nr = 1; > > > Wouldn't it be even more clear with: > > nr /= c->bree_pages || 1; > > instead? No, it is not more clear. At least to me, I may confuse does it mean, - nr = (nr / c->btree_pages) || 1; - or nr = nr / (c->btree_pages || 1) If I don't check C manual, I am not able to tell the correct calculate at first time. Thanks. -- Coly Li ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() 2019-12-12 3:52 ` Coly Li @ 2019-12-12 4:00 ` John Stoffel 0 siblings, 0 replies; 4+ messages in thread From: John Stoffel @ 2019-12-12 4:00 UTC (permalink / raw) To: Coly Li Cc: John Stoffel, Sasha Levin, linux-kernel, stable, Jens Axboe, linux-bcache, linux-raid >>>>> "Coly" == Coly Li <colyli@suse.de> writes: Coly> On 2019/12/12 11:48 上午, John Stoffel wrote: >>>>>>> "Sasha" == Sasha Levin <sashal@kernel.org> writes: >> Sasha> From: Coly Li <colyli@suse.de> Sasha> [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ] >> Sasha> In bch_mca_scan(), the number of shrinking btree node is calculated Sasha> by code like this, Sasha> unsigned long nr = sc->nr_to_scan; >> Sasha> nr /= c->btree_pages; Sasha> nr = min_t(unsigned long, nr, mca_can_free(c)); Sasha> variable sc->nr_to_scan is number of objects (here is bcache B+tree Sasha> nodes' number) to shrink, and pointer variable sc is sent from memory Sasha> management code as parametr of a callback. >> Sasha> If sc->nr_to_scan is smaller than c->btree_pages, after the above Sasha> calculation, variable 'nr' will be 0 and nothing will be shrunk. It is Sasha> frequeently observed that only 1 or 2 is set to sc->nr_to_scan and make Sasha> nr to be zero. Then bch_mca_scan() will do nothing more then acquiring Sasha> and releasing mutex c->bucket_lock. >> Sasha> This patch checkes whether nr is 0 after the above calculation, if 0 Sasha> is the result then set 1 to variable 'n'. Then at least bch_mca_scan() Sasha> will try to shrink a single B+tree node. >> Sasha> nr /= c->btree_pages; Sasha> + if (nr == 0) Sasha> + nr = 1; >> >> >> Wouldn't it be even more clear with: >> >> nr /= c->bree_pages || 1; >> >> instead? Coly> No, it is not more clear. At least to me, I may confuse does it mean, Coly> - nr = (nr / c->btree_pages) || 1; Coly> - or nr = nr / (c->btree_pages || 1) Coly> If I don't check C manual, I am not able to tell the correct Coly> calculate at first time. You're right, it's not quite as clear, it needs proper parenthesis. But maybe instead of a (possibly) expensive division all the time, why not just shift and assume you have it shrink a node, or try to. I honestly haven't looked closely enough at the code to figure out the best shift to use here. But isn't this calculation wrong anyway? If you have lots of c->bree_pages, wouldn't you want to do more freeing? I'd need to read the code better, but I'm heading to bed now. Sorry. John ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-12-12 4:00 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20191211152831.23507-1-sashal@kernel.org>
2019-12-11 15:28 ` [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan() Sasha Levin
2019-12-12 3:48 ` John Stoffel
2019-12-12 3:52 ` Coly Li
2019-12-12 4:00 ` John Stoffel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox