lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 1 Dec 2023 15:27:39 +0800
From:   Yuanhan Zhang <zyhtheonly@...il.com>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     rostedt@...dmis.org, tglx@...utronix.de, mingo@...hat.com,
        peterz@...radead.org, juri.lelli@...hat.com,
        vincent.guittot@...aro.org, linux-kernel@...r.kernel.org,
        dietmar.eggemann@....com, bsegall@...gle.com, mgorman@...e.de,
        bristot@...hat.com, vschneid@...hat.com, zyhtheonly@...h.net
Subject: Re: [PATCH v2] sched/cputime: exclude ktimers threads in irqtime_account_irq

Hi Sebastian, thanks for your reply.

Sebastian Andrzej Siewior <bigeasy@...utronix.de> 于2023年11月30日周四 20:00写道:
>
> On 2023-11-30 17:41:47 [+0800], tiozhang wrote:
> > In CONFIG_PREEMPT_RT kernel, ktimers also calls __do_softirq,
> > so when accounting CPUTIME_SOFTIRQ, ktimers need to be excluded
> > as well as ksoftirqd.
> > Also add this_cpu_ktimers to keep consistency with this_cpu_ksoftirqd.
>
> I'm still not sure what the benefit here is. It says align with
> ksoftirqd but why? Why don't we account softirq time for ksoftirqd (and
> should continue to do so for ktimersd)?

That is my miss. When CONFIG_IRQ_TIME_ACCOUNTING is enabled,
ksoftirqd is counted elsewhere (where ktimers should also be aligned).
Please review my later patch v3.

>
> ktimers runs almost all the time in softirq context. So does every
> force-threaded interrupt. Should we exclude them, too?

For force-threaded interrupt, it counts on CPUTIME_SYSTEM
instead of CPUTIME_IRQ nor CPUTIME_SOFTIRQ.
To me, it does not quite make sense, I'm also thinking of sending a patch
of this, but IMHO it should not be considered in this patch...

>
> Sebastian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ