Re: [PATCH 5/9] bcache: reduce gc latency by processing less nodes and sleep less time

> 2026=E5=B9=B47=E6=9C=8817=E6=97=A5 08:50=EF=BC=8CRobert Pang <robertpang@=
google.com> =E5=86=99=E9=81=93=EF=BC=9A
>=20
> Hi Coly,
>=20
> I was reviewing this patch again and noticed that btree_gc_min_nodes() re=
ads the
> atomic counter 'search_inflight'. This counter is incremented and decreme=
nted by
> clients issuing front-side I/O. In this scenario, should we add a memory =
barrier
> (such as `smp_mb__before_atomic`) prior to `atomic_read()`?=20
>=20
> My concern is that if btree_gc_min_nodes() is inlined in the caller
> btree_gc_recurse(), the compiler might hoist the `atomic_read()` outside =
of the
> while loop where btree_gc_min_nodes() is inlined, preventing us from fetc=
hing the
> latest counter value. Adding the barrier would guarantee we read the upda=
ted
> value.
>=20
> What are your thoughts on this?

Hi Robert,

At the first glance I feel the code was fine. But, it was almost 8 months a=
go, to
make sure I understand you correctly, can you place your comments with the =
exact
code together, then let me response you more accurately.

Thanks for the review.

Coly Li