Messages in this thread | | | From | Yuanhan Zhang <> | Date | Fri, 15 Dec 2023 13:30:10 -0500 | Subject | Re: [PATCH v3] sched/cputime: let ktimers align with ksoftirqd in accounting CPUTIME_SOFTIRQ |
| |
Hi,
Sebastian Andrzej Siewior <bigeasy@linutronix.de> 于2023年12月8日周五 04:26写道: > > On 2023-12-07 13:18:11 [-0500], Steven Rostedt wrote: > > On Thu, 7 Dec 2023 12:19:28 -0500 > > Yuanhan Zhang <zyhtheonly@gmail.com> wrote: > > > > In irqtime_account_process_tick() there's: > > > > if (this_cpu_ksoftirqd() == p) { > > /* > > * ksoftirqd time do not get accounted in cpu_softirq_time. > > * So, we have to handle it separately here. > > * Also, p->stime needs to be updated for ksoftirqd. > > */ > > account_system_index_time(p, cputime, CPUTIME_SOFTIRQ); > > > > Which to me looks like it is counting ksoftirqd for SOFTIRQ time. But > > honestly, why do we care about that? What's the difference if ksoftirqd > > were to run or softirqd were to pass work off to a workqueue? > > > > ksoftirqd runs in vanilla Linux as SCHED_OTHER. The work it does doesn't > > interrupt processes any more than any other kernel thread. I don't know why > > we make it "special". > > The special part is that it runs with disabled preemption the whole time > and the scheduler can't do a thing about it. This is different on > PREEMPT_RT where the softirq is preemptible and scheduler can replace it > with another task if suited. It still runs as SCHED_OTHER. The ktimers/ > thread runs as SCHED_FIFO 1. So accounting it (incl. ksoftirqd) on > SYSTEM is fine IMHO.
I send a [PATCH v4] https://lore.kernel.org/lkml/20231211120209.GA25877@didi-ThinkCentre-M930t-N000/ for making ksoftirqd not special in PREEMPT_RT. It makes SYSTEM more while SOFTIRQ less if we run softirqs on ksoftirqd (eg NET_*).
If you have further comments please let me know. Thanks a lot!
> > > I guess the better question I need to ask is, what is this information used > > for? I thought it was how much time was take away from tasks. As current > > would be a task, and we do care if a real softirq is running, as we do not > > want to add that to the current task accounting. > > > > But for ksoftirqd, that's not the case, and I don't really care if it's > > running a softirq or not. As that time isn't interrupting actual tasks. Not > > to mention, one could simply look at the ksoftirqd tasks to see how much > > time they take up. > > The original argument was to have the softirq counters right in > /proc/stat. This is what I remember from the trip to the museum. > > > -- Steve > > Sebastian
| |