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

[Sebastian Andrzej Siewior]

On 2023-12-01 16:05:41 [+0800], tiozhang wrote:
> In CONFIG_PREEMPT_RT kernel, ktimers also calls __do_softirq,
> so when accounting CPUTIME_SOFTIRQ, ktimers need to be accounted the same
> as ksoftirqd.

I still don't understand why this is a good thing and why want to align
it with ksoftirqd and what breaks if we don't.

This "skip ksoftirqd for accounting" has been added in commit
	b52bfee445d31 ("sched: Add IRQ_TIME_ACCOUNTING, finer accounting of irq time")

At this point (v2.6.37) it had no accounting of time spent in ksoftirqd as
SOFTIRQ time. This was then fixed/ added by commit
	414bee9ba613a ("softirqs: Account ksoftirqd time as cpustat softirq")

which went in v2.6.39. It started accounting it when it was noticed by
the tick. So it is less accurate. The "benefit" seems to be that this
accounting pops up in /proc/stat. As per-CPU or overall.

I *guess* this was to align the softirqs which occur at the end of an
interrupt with those which were outsourced to ksoftirqd because they
took too long. This would patch the wording
	… wanted to see more complete solution in not accounting irq
	processing time to tasks at all.
	https://lore.kernel.org/all/1284688596-6731-1-git-send-email-venki@xxxxxxxxxx/

Or it tried to preserve the current status.

A different account occurs for SOFTIRQs if they occur as port of
hardirq and are maybe deferred to ksoftirqd vs a task raising softirqs
on their own like packet over loopback.
Don't see the benefit that but this is my interpretation based on what
it does.

This was v2.6.39. Since then we got threaded interrupts (also v2.6.39)
or threaded-NAPI which utilise mostly the same mechanism as ksoftirqd
but are treated differently. I don't see why ktimers should align with
ksoftirqd and honestly and I don't understand why ksoftirqd had to be
excluded to in the first place.

Sorry, but I would need to go on than this.

> Signed-off-by: tiozhang <tiozhang@xxxxxxxxxxxxxx>

Sebastian