Messages in this thread | | | Date | Thu, 7 Dec 2023 10:35:36 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH v3] sched/cputime: let ktimers align with ksoftirqd in accounting CPUTIME_SOFTIRQ |
| |
On Thu, 7 Dec 2023 18:43:47 +0800 Yuanhan Zhang <zyhtheonly@gmail.com> 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
| |