Messages in this thread | | | Date | Fri, 5 May 2017 08:02:38 -0400 | From | Steven Rostedt <> | Subject | Re: [PATCH tip/sched/core v2] sched/rt: Simplify the IPI rt balancing logic |
| |
On Fri, 5 May 2017 13:05:29 +0200 Peter Zijlstra <peterz@infradead.org> wrote:
> On Thu, May 04, 2017 at 03:03:55PM -0400, Steven Rostedt wrote: > > My test case is two fold. It basically just involves running rteval. > > > > One is to run it on latest mainline to make sure it doesn't crash. The > > other is to backport it to the latest -rt patch, and see how well it > > helps with latency. > > > > To get rteval: > > > > $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rteval.git > > $ cd rteval > > $ git checkout origin/v2/master > > Blergh, that thing wants a gazillion things installed.
Blame Clark and friends ;-)
> > Can't I run something simple like rt-migrate-test with some arguments to > stress the box out?
Actually what rteval does is basically 3 things. It runs cyclictest, hackbench in a loop and a kernel build in a loop.
Note, rteval binds the the hackbench and kernel builds to nodes. That is, if you have 4 nodes, it will run four instances of loops of both hackbench and kernel builds in each of the nodes. This is because hackbench and access to the filesystem across nodes with a stress test can cause exorbitant latency due to cross node memory access on spin locks.
I usually run cyclictest with:
cyclictest -p80 -i250 -n -a -t -q -d 0
Although I think rteval does it slightly different. Like adding --numa to it.
Clark, want to explain more?
-- Steve
| |