lkml.org 
[lkml]   [2014]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [LKP] [rcu] c0f489d2c6f: -1.5% netperf.Throughput_tps
    From
    Date
    On Fri, 2014-07-25 at 16:05 +0800, Aaron Lu wrote: 
    > On 07/25/2014 03:35 PM, Mike Galbraith wrote:
    > > On Fri, 2014-07-25 at 14:45 +0800, Aaron Lu wrote:
    > >> FYI, we noticed the below changes on
    > >>
    > >> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
    > >> commit c0f489d2c6fec8994c642c2ec925eb858727dc7b ("rcu: Bind grace-period kthreads to non-NO_HZ_FULL CPUs")
    > >>
    > >> abaa93d9e1de2c2 c0f489d2c6fec8994c642c2ec
    > >> --------------- -------------------------
    > >> 12654 ~ 0% -1.5% 12470 ~ 0% ivb43/netperf/300s-25%-TCP_CRR
    > >> 12654 ~ 0% -1.5% 12470 ~ 0% TOTAL netperf.Throughput_tps
    > >
    > > Out of curiosity, what parameters do you use for this test? In my
    >
    > The cmdline for this test is:
    > netperf -t TCP_CRR -c -C -l 300

    Thanks. That doesn't switch as heftily as plain TCP_RR, but I'd still
    expect memory layout etc to make bisection frustrating as heck. But no
    matter, I was just curious.

    Aside: running unbound, the load may get beaten up pretty bad by nohz if
    it's enabled. Maybe for testing the network stack it'd be better to
    remove that variable? Dunno, just a thought. I only mention it because
    your numbers look very low unless the box is ancient or CPU is dinky.

    -Mike



    \
     
     \ /
      Last update: 2014-07-25 12:41    [W:4.123 / U:0.280 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site