[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201109124718.ljf7inok4zakkjed@linutronix.de>
Date: Mon, 9 Nov 2020 13:47:18 +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-06 17:14:13 [+0100], Daniel Wagner wrote:
> On Fri, Nov 06, 2020 at 11:54:47AM +0100, Sebastian Andrzej Siewior wrote:
> > > 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.0-rc8-rt13
> 1196 0_signaltest t0-max-latency : fail 207.00
> 1196 0_signaltest t0-avg-latency : pass 46.00
> 1196 0_signaltest t0-min-latency : pass 22.00
> rpi3 signaltest 5.9.0-rc8-rt14
> 1197 0_signaltest t0-max-latency : fail 301.00
> 1197 0_signaltest t0-avg-latency : pass 47.00
> 1197 0_signaltest t0-min-latency : pass 20.00
> rpi3 signaltest 5.9.0-rt15
> 1198 0_signaltest t0-max-latency : fail 323.00
> 1198 0_signaltest t0-avg-latency : pass 47.00
> 1198 0_signaltest t0-min-latency : pass 21.00
So it is the new migrate-disable code? If you have stable 100us you
should be able bisect it within the few commits between rt13 and rt14.
> > > 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
> >
> > So I have nothing to explain 20us improvement.
>
> I think 20us is in the range of the standard deviation for this test. So
> I don't think you should be concerned too much about it as long I don't
> have proper statistical numbers.
>
> One thing I also see is that the average was pretty constant at 47us for
> 5.9-rt and for 5.10-rt series it's around 55us. So something makes the
> whole operation slightly more expensive.
>
> > > 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
>
> rpi3 signaltest 5.10.0-rc1-rt2
> 1199 0_signaltest t0-max-latency : fail 399.00
> 1199 0_signaltest t0-avg-latency : pass 55.00
> 1199 0_signaltest t0-min-latency : pass 25.00
> rpi3 signaltest 5.10.0-rc2-rt3
> 1200 0_signaltest t0-max-latency : fail 420.00
> 1200 0_signaltest t0-avg-latency : pass 55.00
> 1200 0_signaltest t0-min-latency : pass 25.00
this looks odd. So rt1 has 415, rt2 has 399 and rt3 has 420 so lets say
it is the same. And then rt4 should reduce it to 340. The only part that
could have some influence is the are the highmem/kmap patches. But for
ARM64 these are still a nop and in both cases kmap_atomic() disables
migrate & page-fault.
Are you sure those numbers always reproducible and not something that
goes wrong and sometimes it is captured at 300us and sometimes 400us.
I've been staring at the code of signaltest on Friday and I might need
to stare longer to figure out what it does.
Sebastian
Powered by blists - more mailing lists