Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic

[Peter Zijlstra]

On Fri, May 05, 2017 at 02:59:16PM -0400, Steven Rostedt wrote:
> On Fri, 5 May 2017 19:39:49 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.