Re: [PATCH v2] sched: Account cgroup CPU time to the execution context

[Hui Su]

On Tue, Sep 8, 2026 at 10:17 PM John Stultz <jstultz@xxxxxxxxxx> wrote:
>
> I believe I'm ok with this if you are. Commit aa4f74dfd42b ("sched:
> Fix runtime accounting w/ split exec & sched contexts") was trying to
> allow the owner's cputime to make sense in top, but we still want the
> donor to be "donating" their time, so I thought the compromise of
> charging the donor's cgroup would make more sense. I'm imagining
> something like the cpu bandwidth controllers, where it seemed like the
> donor's cgroup is who we'd want to charge, and eventually throttle,
> even though it is donating time to the lock owner to run (since even
> if the lock owner's cgroup was throttled, proxying will let the donor
> "bust" through the limit and run the lock owner using the donor's
> bandwidth - up until the donor's bandwidth was exceeded).
>
> But if it is causing trouble for the accounting, and you think it
> makes more sense the other way, I'll trust your judgement.
> Tentatively:
>    Acked-by: John Stultz <jstultz@xxxxxxxxxx>
>
> Eventually I think we'll want to track per-task "donated" and "gifted"
> time so folks can more finely distinguish the accounting.
>
> thanks
> -john

Thanks John and Tejun.

One distinction that may help here is that this patch only changes the
cgroup CPU usage accounting performed by cgroup_account_cputime(). It
does not change CFS bandwidth accounting.

Under proxy execution, update_curr() still accounts CFS bandwidth
through account_cfs_rq_runtime() on the cfs_rq associated with the
scheduling context. Thus, the donor's scheduling bandwidth continues
to be consumed as before; this patch does not change the bandwidth or
throttling behavior John described.

The change here only makes the observable cgroup CPU usage accounting
follow the task that actually executed, in line with the per-task,
thread-group, and cgroup user/system accounting.

The donated/gifted accounting you mention sounds useful for exposing
both sides explicitly, but I agree that would be separate follow-up
work.

Thanks,
Hui