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

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

[Hui Su]

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@kernel.org>
Signed-off-by: Hui Su <sh_def@163.com>
---
Changes since v1:
- Rework the fix following Tejun Heo's review: make cgroup CPU usage
  follow the execution context instead of moving cgroup user/system
  accounting to the scheduling context.
- Drop the per-rq cputime owner, deferred boundary handling, and donor
  lifetime tracking, which are no longer needed.
- Rework the reproducer expectation around execution-context cgroup
  CPU usage.

Testing:
- cgroup v2 proxy reproducer: executor runtime +1.483s, donor cgroup A
  usage +0, and executor cgroup B usage +1.629s.
- RT donor reproducer: executor runtime +0.991s, donor cgroup A usage
  +125us, and executor cgroup B usage +0.991s.
- cgroup v1 cpuacct: usage charged to the executor cgroup.
- sched_proxy_exec=off control passed.
- CONFIG_SCHED_PROXY_EXEC / CONFIG_CGROUPS /
  CONFIG_CGROUP_CPUACCT build matrix passed.
- W=1 kernel/sched/fair.o passed.
- checkpatch --strict and git diff --check passed.

v1: https://lore.kernel.org/lkml/5733b51108eda90c1bda98a68d58b5e6ccbc24ec.1788433334.git.sh_def@163.com/

 kernel/sched/fair.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8dff37059faf..6fcf67d741e8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1404,7 +1404,6 @@ static s64 update_se(struct rq *rq, struct sched_entity *se)
 
 	se->exec_start = now;
 	if (entity_is_task(se)) {
-		struct task_struct *donor = task_of(se);
 		struct task_struct *running = rq->curr;
 		/*
 		 * If se is a task, we account the time against the running
@@ -1417,8 +1416,7 @@ static s64 update_se(struct rq *rq, struct sched_entity *se)
 		account_group_exec_runtime(running, delta_exec);
 		account_mm_sched(rq, running, delta_exec);
 
-		/* cgroup time is always accounted against the donor */
-		cgroup_account_cputime(donor, delta_exec);
+		cgroup_account_cputime(running, delta_exec);
 	} else {
 		/* If not task, account the time against donor se  */
 		se->sum_exec_runtime += delta_exec;
-- 
2.54.0

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

[Tejun Heo]

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@kernel.org>
> Signed-off-by: Hui Su <sh_def@163.com>

Provided John is okay with going this way:

Acked-by: Tejun Heo <tj@kernel.org>

> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8dff37059faf..6fcf67d741e8 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1404,7 +1404,6 @@ static s64 update_se(struct rq *rq, struct sched_entity *se)
>  
>  	se->exec_start = now;
>  	if (entity_is_task(se)) {
> -		struct task_struct *donor = task_of(se);
>  		struct task_struct *running = rq->curr;
>  		/*
>  		 * If se is a task, we account the time against the running
> @@ -1417,8 +1416,7 @@ static s64 update_se(struct rq *rq, struct sched_entity *se)
>  		account_group_exec_runtime(running, delta_exec);
>  		account_mm_sched(rq, running, delta_exec);
>  
> -		/* cgroup time is always accounted against the donor */
> -		cgroup_account_cputime(donor, delta_exec);
> +		cgroup_account_cputime(running, delta_exec);

The diff looks so much better.

Thanks.

-- 
tejun

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@kernel.org> 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@kernel.org>
> > Signed-off-by: Hui Su <sh_def@163.com>
>
> Provided John is okay with going this way:
>
> Acked-by: Tejun Heo <tj@kernel.org>

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@google.com>

Eventually I think we'll want to track per-task "donated" and "gifted"
time so folks can more finely distinguish the accounting.

thanks
-john

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@google.com> 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@google.com>
>
> 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

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

[Tejun Heo]

Hello,

On Tue, Sep 08, 2026 at 10:17:45PM -0700, John Stultz wrote:
...
> 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@google.com>
> 
> Eventually I think we'll want to track per-task "donated" and "gifted"
> time so folks can more finely distinguish the accounting.

Yeah, I want the cgroup base stats to agree with what's reported for
threads. This makes it disagree with bw enforcement but I think it makes
more sense to bridge that gap with explicit stats for proxy execution like
you're suggesting.

Thanks.

-- 
tejun