linux-kernel - Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level IRQ time accounting

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]

Message-ID: <20200805134002.GQ2674@hirez.programming.kicks-ass.net>
Date:   Wed, 5 Aug 2020 15:40:02 +0200
From:   peterz@...radead.org
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Valentin Schneider <valentin.schneider@....com>,
        Vladimir Oltean <olteanv@...il.com>,
        Kurt Kanzenbach <kurt.kanzenbach@...utronix.de>,
        Alison Wang <alison.wang@....com>, catalin.marinas@....com,
        will@...nel.org, paulmck@...nel.org, mw@...ihalf.com,
        leoyang.li@....com, vladimir.oltean@....com,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        Anna-Maria Gleixner <anna-maria@...utronix.de>
Subject: Re: [RFC PATCH] arm64: defconfig: Disable fine-grained task level
 IRQ time accounting

On Mon, Aug 03, 2020 at 09:22:53PM +0200, Thomas Gleixner wrote:

>    totaltime = irqtime + tasktime
> 
> Ignoring irqtime and pretending that totaltime is what the scheduler
> can control and deal with is naive at best.

Well no, that's what we call system overhead and is assumed to be
included in the 'error margin'.

The way things are set up is that we say that, by default, RT tasks can
consume 95% of cputime and the remaining 5% is sufficient to keep the
system alive.

Those 5% include all system overhead, IRQs, RCU, !RT workqueues etc..

Obviously IRQ_TIME accounting changes the balance a bit, but that's what
it is. We can't really do anything better.

Apparently this SoC has significant IRQ time for some reason. Also,
relying on RT throttling for 'correct' behaviour is also wrong. What
needs to be done is find who is using all this RT time and why, that
isn't right.