Thread (4 messages) 4 messages, 3 authors, 2019-12-12

Re: [PATCH AUTOSEL 4.14 32/58] bcache: at least try to shrink 1 node in bch_mca_scan()

From: John Stoffel <hidden>
Date: 2019-12-12 04:00:42
Also in: linux-bcache, lkml, stable

quoted
quoted
quoted
quoted
"Coly" == Coly Li [off-list ref] writes:
Coly> On 2019/12/12 11:48 上午, John Stoffel wrote:
quoted
quoted
quoted
quoted
quoted
quoted
"Sasha" == Sasha Levin [off-list ref] writes:
Sasha> From: Coly Li [off-list ref]
Sasha> [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ]
quoted
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;
quoted
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.
quoted
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.
quoted
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.
quoted
Sasha> nr /= c->btree_pages;
Sasha> +	if (nr == 0)
Sasha> +		nr = 1;
quoted

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help