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

[John Stultz]

On Thu, Sep 3, 2026 at 11:37 PM Tejun Heo <tj@xxxxxxxxxx> wrote:
>
> On Fri, Sep 04, 2026 at 11:47:07AM +0800, Hui Su wrote:
> > Proxy execution separates the scheduling context from the execution
> > context. Commit aa4f74dfd42b ("sched: Fix runtime accounting w/ split
> > exec & sched contexts") made per-task and thread-group runtime
> > accounting follow the task that actually executes, while cgroup CPU
> > usage is charged to the donor.
> >
> > When the donor and execution task belong to different cgroups, this
> > makes a task's execution time count against a different cgroup from the
> > one the task belongs to.
> >
> > Cgroup CPU usage should follow the execution context, matching the
> > per-task, thread-group, and cgroup user/system accounting. Keep
> > scheduling state associated with the donor, but charge cgroup CPU
> > usage to rq->curr.
> >
> > A reproducer with the donor and execution task in separate cgroups
> > showed the execution task accumulating runtime while cgroup CPU usage
> > was charged to the donor's cgroup. With this change, the execution
> > task's cgroup accumulates the CPU usage instead. The same behavior was
> > verified with an RT donor and with legacy cpuacct accounting.
> >
> > Fixes: aa4f74dfd42b ("sched: Fix runtime accounting w/ split exec & sched contexts")
> > Suggested-by: Tejun Heo <tj@xxxxxxxxxx>
> > Signed-off-by: Hui Su <sh_def@xxxxxxx>
>
> Provided John is okay with going this way:
>
> Acked-by: Tejun Heo <tj@xxxxxxxxxx>

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