On 2023/5/23 Michal Koutný wrote:
Hello Jia.
On Fri, May 19, 2023 at 12:15:57PM +0800, Hao Jia <jiahao.os@xxxxxxxxxxxxx> wrote:
Maybe something like this?
(Next time please send with a version bump in subject.)
Thanks for your review, I will do it in the next version.
In cgroup_base_stat_flush() function, {rstatc, cgrp}->last_bstat
needs to be updated to the current {rstatc, cgrp}->bstat after the
calculation.
For the rstatc->last_bstat case, rstatc->bstat may be updated on other
cpus during our calculation, resulting in inconsistent rstatc->bstat
statistics for the two reads. So we use the temporary variable @cur to
record the read statc->bstat statistics, and use @cur to update
rstatc->last_bstat.
If a concurrent update happens after sample of bstat was taken for
calculation, it won't be reflected in the flushed result.
But subsequent flush will use the updated bstat and the difference from
last_bstat would account for that concurrent change (and any other
changes between the flushes).
IOW flushing cannot prevent concurrent updates but it will give
eventually consistent (repeated without more updates) results.
Yes, so we need @curr to record the bstat value after the sequence fetch
is completed.
It is better for us to assign directly instead of using
cgroup_base_stat_add() to update {rstatc, cgrp}->last_bstat.
Or do you mean the copying is faster then arithmetics?
Yes, but it may not be obvious.
Another reason is that when we complete an update, we snapshot
last_bstat as the current bstat, which is better for readers to
understand. Arithmetics is somewhat obscure.
Thanks,
Hao
