Skip to content

sched/critmon: Fix CPU load stats incorrect when using SCHED_CPULOAD_CRITMONITOR#18485

Merged
linguini1 merged 1 commit intoapache:masterfrom
anchao:26030301
Mar 3, 2026
Merged

sched/critmon: Fix CPU load stats incorrect when using SCHED_CPULOAD_CRITMONITOR#18485
linguini1 merged 1 commit intoapache:masterfrom
anchao:26030301

Conversation

@anchao
Copy link
Contributor

@anchao anchao commented Mar 3, 2026

Summary

sched/critmon: Fix CPU load stats incorrect when using SCHED_CPULOAD_CRITMONITOR

Fix the abnormal CPU usage statistics issue caused by missing update
of run_start timestamp in the target task (to) TCB when the CPU load
counting mode is SCHED_CPULOAD_CRITMONITOR.

Before this fix, the to->run_start was not set when switching context,
leading to incorrect CPU usage calculation (e.g., Idle_Task showed 52.9%
CPU usage instead of 100%, and running tasks had wrong non-zero values).
After fixing, the CPU statistics return to normal: Idle_Task correctly
shows 100% usage, and non-running tasks show 0% as expected.

Enable:

+CONFIG_SCHED_CPULOAD_CRITMONITOR=y
+CONFIG_SCHED_CRITMONITOR=y

Before:

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 52.9% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7b4417a003f0 0x7b4417a00470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464 17.6% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496 36.8% nsh_main

After:

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 100.0% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7646932003f0 0x764693200470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464  0.0% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496  0.0% nsh_main

This issue was introduced by PR #17075, where the run_start update for the
target task was omitted in the SCHED_CPULOAD_CRITMONITOR branch.

Signed-off-by: chao an anchao.archer@bytedance.com

Impact

N/A

Testing

sim/nsh,

Enable:

+CONFIG_SCHED_CPULOAD_CRITMONITOR=y
+CONFIG_SCHED_CRITMONITOR=y

Before:

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 52.9% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7b4417a003f0 0x7b4417a00470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464 17.6% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496 36.8% nsh_main

After:

nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 100.0% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7646932003f0 0x764693200470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464  0.0% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496  0.0% nsh_main

…CRITMONITOR

Fix the abnormal CPU usage statistics issue caused by missing update
of run_start timestamp in the target task (to) TCB when the CPU load
counting mode is SCHED_CPULOAD_CRITMONITOR.

Before this fix, the to->run_start was not set when switching context,
leading to incorrect CPU usage calculation (e.g., Idle_Task showed 52.9%
CPU usage instead of 100%, and running tasks had wrong non-zero values).
After fixing, the CPU statistics return to normal: Idle_Task correctly
shows 100% usage, and non-running tasks show 0% as expected.

Enable:
+CONFIG_SCHED_CPULOAD_CRITMONITOR=y
+CONFIG_SCHED_CRITMONITOR=y

Before:
nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 52.9% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7b4417a003f0 0x7b4417a00470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464 17.6% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496 36.8% nsh_main

After:
nsh> ps
  TID   PID  PPID PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK    CPU COMMAND
    0     0     0   0 FIFO     Kthread   - Ready              0000000000000000 0069584 100.0% Idle_Task
    1     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067456  0.0% sim_loop_wq 0x7646932003f0 0x764693200470
    2     0     0 224 FIFO     Kthread   - Waiting  Semaphore 0000000000000000 0067464  0.0% hpwork 0x4014dba0 0x4014dc20
    3     3     0 100 FIFO     Task      - Running            0000000000000000 0067496  0.0% nsh_main

This issue was introduced by PR apache#17075, where the run_start update for the
target task was omitted in the SCHED_CPULOAD_CRITMONITOR branch.

Signed-off-by: chao an <anchao.archer@bytedance.com>
@github-actions github-actions bot added Area: OS Components OS Components issues Size: XS The size of the change in this PR is very small labels Mar 3, 2026
@linguini1 linguini1 merged commit d5b02b6 into apache:master Mar 3, 2026
40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Area: OS Components OS Components issues Size: XS The size of the change in this PR is very small

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants