lkml.org 
[lkml]   [2023]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2023-12-15 19:31    [W:0.135 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site