Chen Ridong chenridong@huaweicloud.com writes:
...
Thanks,
What I mean by "stable" is that while cgroup 1 through n might be deleted or have more descendants created. For example:
n n-1 n-2 ... 1frozen a a+1 a+2 a+n unfozen b b+1 b+2 ... b+n nsec b-a ...
In this case, all frozen_nsec values are b - a, which I believe is correct. However, consider a scenario where some cgroups are deleted:
n n-1 n-2 ... 1frozen a a+1 a+2 a+n // 2 ... n-1 are deleted. unfozen b b+1
Here, the frozen_nsec for cgroup n would be b - a, but for cgroup 1 it would be (b + 1) - (a + n). This could introduce some discrepancy / timing inaccuracies.
Ah, I think I see what you're saying. I had a similar concern when I had been looking to track this value per-task rather than per-cgroup (i.e., when there are many tasks, the frozen duration recorded for the cgroup drifts from the duration that the task is actually frozen). Ultimately, although those inaccuracies exist, for the time scales in our use case, they would not grow large enough to make an appreciable difference. To use your example, the ~(n - 1) difference between the "true" frozen duration and the reported one is still effectively the same (to us). For others, their systems may see a much larger "n" than we might realistically see on ours, or they may need finer-grained reporting, so this solution may not be adequate.