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
