Received-SPF: pass (google.com: domain of linux-kernel+bounces-1532-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20231201073240.T9bFNCkU@linutronix.de> <20231201080522.GA31309@didi-ThinkCentre-M930t-N000>
 <20231201161640.Z0cJLUi3@linutronix.de> <CAEQmJ=jbB5ag5HRMjZqjych_wj_v6wTMLQxJbnJsgwNdn37kbw@mail.gmail.com>
 <20231205153146.OSpCIs1G@linutronix.de> <CAEQmJ=iNVUuQQrm4bJgud=e7yhgwNb4Q1-BgOQF98D7NP9r29A@mail.gmail.com>
 <20231207103536.30ae05aa@gandalf.local.home> <CAEQmJ=jceiVevd9d3i4h0BHCNc8FFONJqEaiKyN9p21rg0QdkQ@mail.gmail.com>
 <20231207131811.08145840@gandalf.local.home> <20231208092616.LcwLlOyE@linutronix.de>
In-Reply-To: <20231208092616.LcwLlOyE@linutronix.de>
From: Yuanhan Zhang <zyhtheonly@gmail.com>
Date: Fri, 15 Dec 2023 13:30:10 -0500
Message-ID: <CAEQmJ=jOyntcD0Vw2AL6cH-ACD7TKbW7nqjMBmHB=EUjF1DUYA@mail.gmail.com>
Subject: Re: [PATCH v3] sched/cputime: let ktimers align with ksoftirqd in
 accounting CPUTIME_SOFTIRQ
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>, zyhtheonly@yeah.net, tglx@linutronix.de, 
	mingo@redhat.com, Venkatesh Pallipadi <venki@google.com>, peterz@infradead.org, 
	juri.lelli@redhat.com, vincent.guittot@linaro.org, 
	linux-kernel@vger.kernel.org, dietmar.eggemann@arm.com, bsegall@google.com, 
	mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Sebastian Andrzej Siewior <bigeasy@linutronix.de> =E4=BA=8E2023=E5=B9=B412=
=E6=9C=888=E6=97=A5=E5=91=A8=E4=BA=94 04:26=E5=86=99=E9=81=93=EF=BC=9A
>
> 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() =3D=3D p) {
> >               /*
> >                * ksoftirqd time do not get accounted in cpu_softirq_tim=
e.
> >                * 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 curren=
t
> > 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 muc=
h
> > 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