[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161011103957.GC16071@codeblueprint.co.uk>
Date: Tue, 11 Oct 2016 11:39:57 +0100
From: Matt Fleming <matt@...eblueprint.co.uk>
To: Dietmar Eggemann <dietmar.eggemann@....com>
Cc: Vincent Guittot <vincent.guittot@...aro.org>,
Wanpeng Li <kernellwp@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mike Galbraith <umgwanakikbuti@...il.com>,
Yuyang Du <yuyang.du@...el.com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
On Tue, 11 Oct, at 10:44:25AM, Dietmar Eggemann wrote:
>
> [...]
>
> Yeah, you're right. But I can't see any significant difference. IMHO,
> it's all in the noise.
>
> (A) Performance counter stats for 'perf bench sched messaging -g 100 -l
> 1 -t'
> # 20 sender and receiver threads per group
> # 100 groups == 4000 threads run
>
FWIW, our tests run with 1000 loops, not 1, and we don't use 100
groups for low cpu machines. We tend to test upto $((nproc * 4)).
Powered by blists - more mailing lists