Messages in this thread | | | Date | Wed, 24 May 2023 14:54:10 +0800 | Subject | Re: [External] Re: [PATCH] cgroup: rstat: Simplified cgroup_base_stat_flush() update last_bstat logic | From | Hao Jia <> |
| |
On 2023/5/23 Michal Koutný wrote: > Hello Jia. > > On Fri, May 19, 2023 at 12:15:57PM +0800, Hao Jia <jiahao.os@bytedance.com> 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
| |