linux-kernel - Re: [ANNOUNCE] v5.10-rc2-rt4

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: <20201106105447.2lasulgjrbqdhnlh@linutronix.de>
Date:   Fri, 6 Nov 2020 11:54:47 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Daniel Wagner <wagi@...om.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [ANNOUNCE] v5.10-rc2-rt4

On 2020-11-04 17:06:50 [+0100], Daniel Wagner wrote:
> On Wed, Nov 04, 2020 at 02:09:30PM +0100, Sebastian Andrzej Siewior wrote:
> > Could you figure out if the arm64 thingy started with -rt4 or was
> > already in rt3?
> 
> I wrote a quick and dirty script to extract the data from my logs to see
> if the regression might be older then I remembered. I filtered out the
> obviously wrong configured runs (e.g !RT). It looks like the first
> recorded outlier is around 5.9.0-rt16. Does this already help or do you
> want me to bissect it down?

> rpi3    signaltest      5.9.0-rc8-rt12
>   813   0_signaltest         t0-max-latency      : fail     214.00
> rpi3    signaltest      5.9.0-rc8-rt12
>   874   0_signaltest         t0-max-latency      : fail     217.00
> rpi3    signaltest      5.9.0-rt16
>   963   0_signaltest         t0-max-latency      : fail     321.00

Here, rt 13,14,15 would be interesting so we could narrow down the
~100us.
v5.9-rc8-rt14 got new migrate-disable but I wouldn't expect it to cause
it. The other changes look also harmless (like the rtmutex redo which
should be a 0 change but then it mighe behave differently in regard to
workqueue in some corner cases).

> rpi3    signaltest      5.9.1-rt19
>   1038  0_signaltest         t0-max-latency      : fail     341.00
> rpi3    signaltest      5.9.1-rt20
>   1079  0_signaltest         t0-max-latency      : fail     318.00

Looking from my announcement:
|      - Tiny update to the rtmutex patches (make __read_rt_trylock()
|        static).

this could improve things but not that much.

|      - The test_lockup module failed to compile. Reported by Fernando
|        Lopez-Lezcano.

unrelated.

|      - The `kcompactd' daemon together with MEMCG could have accessed
|        per-CPU variables in preemtible context.

an additional lock…

|      - The patch for the crash in the block layer (previously reported by
|        David Runge) has been replaced with another set of patches which
|        were submitted upstream.

looks also innocent.

So I have nothing to explain 20us improvement.

> rpi3    signaltest      5.10.0-rc1-rt1
>   1118  0_signaltest         t0-max-latency      : fail     415.00
> rpi3    signaltest      5.10.0-rc2-rt4
>   1163  0_signaltest         t0-max-latency      : fail     340.00

-rt2 gained new kmap code.
-rt3 received an update of the above

This is the only outstanding thing between rt1 and rt4.

But all this is only signal right? Nothing on the cyclictest front? If
lazy-preempt broke in a way then it should be only noticed by
cyclictest. You can however disable lazy-preempt just to be sure.

Sebastian