On Fri, May 05, 2017 at 02:59:16PM -0400, Steven Rostedt wrote:
> On Fri, 5 May 2017 19:39:49 +0200
> Peter Zijlstra <[email protected]> wrote:
>
> > On Fri, May 05, 2017 at 08:02:38AM -0400, Steven Rostedt wrote:
> > > Actually what rteval does is basically 3 things. It runs cyclictest,
> > > hackbench in a loop and a kernel build in a loop.
> >
> > Of those, only cyclictest uses RT tasks and would end up poking at the
> > bits you just changed.
> >
> > So just running cyclictest should lock up a ~120 CPU machine?
>
> The other tools tend to trigger RT kernel threads as well, which causes
> migration. cyclictest tasks don't migrate, but they do cause other
> tasks to want to move around.
There aren't that many RT threads on a !RT kernel. All my laptop has for
example are:
$ ps -faxo pid,class,comm | grep -v TS
PID CLS COMMAND
9 FF \_ migration/0
10 FF \_ watchdog/0
11 FF \_ watchdog/1
12 FF \_ migration/1
16 FF \_ watchdog/2
17 FF \_ migration/2
21 FF \_ watchdog/3
22 FF \_ migration/3
714 FF \_ irq/48-iwlwifi
24254 FF \_ irq/47-mei_me
2444 B \_ baloo_file
> You can try rt-migrate-test too, because I used that to trigger some
> bugs in previous versions.
Just running rt-migrate-test 'works' on the 144 CPU box. But I ran it
while it was otherwise idle. That is, it ran in reasonable time and no
lockup messages were produced.
I can try and run it together with cyclictest, but over all this sounds
like we're missing a usable test-case. If I have a spare moment (lol) I
might poke at rt-migrate-test to see if I can make it more aggressive or
something.
