[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 May 2017 14:59:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
Clark Williams <williams@...hat.com>,
Daniel Bristot de Oliveira <bristot@...hat.com>,
John Kacur <jkacur@...hat.com>, Scott Wood <swood@...hat.com>
Subject: Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt
balancing logic
On Fri, 5 May 2017 19:39:49 +0200
Peter Zijlstra <peterz@...radead.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.
You can try rt-migrate-test too, because I used that to trigger some
bugs in previous versions.
-- Steve
Powered by blists - more mailing lists