Re: [PATCH v2] sched/stat: correct the task blocking state

From: Alex Shi
Date: Thu Jan 04 2024 - 06:29:57 EST


On Thu, Jan 4, 2024 at 6:38 PM Valentin Schneider <vschneid@xxxxxxxxxx> wrote:
>
> On 03/01/24 16:10, alexs@xxxxxxxxxx wrote:
> > From: Alex Shi <alexs@xxxxxxxxxx>
> >
> > The commit 80ed87c8a9ca ("sched/wait: Introduce TASK_NOLOAD and TASK_IDLE")
> > stopped the idle kthreads from contributing to the load average. However,
> > the idle state time still contributes to the blocked state time instead of
> > the sleep time. As a result, we cannot determine if a task is stopped due
> > to some reasons or if it is idle by its own initiative.
> >
> > Distinguishing between these two states would make the system state clearer
> > and provide us with an opportunity to use the 'D' state of a task as an
> > indicator of latency issues.
> >
>
> get_task_state() already reports TASK_IDLE as 'I', which should be what
> userspace sees (e.g. via /proc/$pid/stat). This is also the case for the
> sched_switch and sched_wakeup trace events.
>
> I assume what you mean here is you first turn to schedstats to check
> whether there is any abnormal amount of blocking, and then if there is any
> you turn to tracing, in which case you'd like the schedstats to not make
> things look worse than they really are?

Yes, switch/wakeup or others could help to figure out real blocked
time, but with this change, schedstats could give a neat and elegant
way.

Thanks!
>