On Fri, 5 May 2017 13:05:29 +0200 Peter Zijlstra <[email protected]> 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
