[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5g73i4yvi4ub4dqrf4dnq5qghkyckoygmgd2st6be3gg7twww2@w6zim6nxpt3b>
Date: Tue, 23 May 2023 17:14:28 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Hao Jia <jiahao.os@...edance.com>
Cc: tj@...nel.org, lizefan.x@...edance.com, hannes@...xchg.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup: rstat: Simplified cgroup_base_stat_flush()
update last_bstat logic
Hello Jia.
On Fri, May 19, 2023 at 12:15:57PM +0800, Hao Jia <jiahao.os@...edance.com> wrote:
> Maybe something like this?
(Next time please send with a version bump in subject.)
> 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.
> 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?
Thanks,
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists