public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
* [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