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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux