lkml.org 
[lkml]   [2017]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2017-05-05 14:03    [W:2.399 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site