Re: [PATCH v3] sched/cputime: let ktimers align with ksoftirqd in accounting CPUTIME_SOFTIRQ

[Steven Rostedt]

On Thu, 7 Dec 2023 18:43:47 +0800
Yuanhan Zhang <zyhtheonly@xxxxxxxxx> wrote:

> It results in if we do not handle ksoftirqd like this, we will have a
> bigger SYSTEM and less SOFTIRQ.

And honestly that's what we want. Interrupts and softirqs that execute in
interrupts and softirq context take away from the system. That is, if they
are not explicitly blocked (local_irq_disable/local_bh_disable) they
interrupt the current task and take up the time of the current task. We
need to differentiate this because this context has no "task" context to
measure.

We do not want to add ksoftirqd or threaded interrupt handlers / softirqs
to this measurement. Sure, they are handling interrupt and softirq code,
but they have their own context that can be measured like any other task.

If we blur this with real irqs and softirqs, then we will not know what
those real irqs and softirqs are measuring.

> So my point is if we do not align ktimers, ktimers would act like
> **observation on *not-excluded ksoftirq patched* kernel** part in the
> above example,
> and this might make SOFTIRQ less than expected, /proc/stat less accurate.

No it does not. When a softirq kicks off it's work to a thread (ksoftirq,
threaded softirqd, or simply a workqueue), it's no longer running in
softirq context, and should not be measured as such.

The measurement is not about how much work the softirq is doing (otherwise
we need to add workqueues started by softirqs too), it's about measuring
the actual irq and softirq context. In PREEMPT_RT, we try to eliminate that
context as much as possible.

So seeing less is a feature not a bug!

-- Steve