Messages in this thread | | | Date | Sat, 6 May 2017 09:52:38 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic |
| |
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@infradead.org> 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.
| |