Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1755606AbcJRKLe (ORCPT <rfc822;w@1wt.eu>);
        Tue, 18 Oct 2016 06:11:34 -0400
Received: from mail-qt0-f170.google.com ([209.85.216.170]:33433 "EHLO
        mail-qt0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752313AbcJRKL1 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 18 Oct 2016 06:11:27 -0400
Date: Tue, 18 Oct 2016 11:11:19 +0100
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Dietmar Eggemann <dietmar.eggemann@arm.com>
Cc: Vincent Guittot <vincent.guittot@linaro.org>,
        Wanpeng Li <kernellwp@gmail.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Yuyang Du <yuyang.du@intel.com>
Subject: Re: [PATCH] sched/fair: Do not decay new task load on first enqueue
Message-ID: <20161018101119.GH16071@codeblueprint.co.uk>
References: <20160923115808.2330-1-matt@codeblueprint.co.uk>
 <20160928101422.GR5016@twins.programming.kicks-ass.net>
 <20160928193731.GD16071@codeblueprint.co.uk>
 <CANRm+CyVFuT3XJt7DZEBZgHb_hQPzDUfOGnkAqNexH4q2ex74Q@mail.gmail.com>
 <20161010100107.GZ16071@codeblueprint.co.uk>
 <CAKfTPtBFrahA2fBoG5S5CBiJHb8EZkUbPaOZ4jZFc1mVYH5zJQ@mail.gmail.com>
 <f2091da3-b96e-d26c-8db7-a1db2d9237ae@arm.com>
 <CAKfTPtCsM0T0wKMnbqu556kJLTu9gGQs874uLp84hDjqs3+U5Q@mail.gmail.com>
 <43581f1a-fee7-5547-7946-ec1ffcfd64f1@arm.com>
 <20161011103957.GC16071@codeblueprint.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20161011103957.GC16071@codeblueprint.co.uk>
User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 1122
Lines: 28

On Tue, 11 Oct, at 11:39:57AM, Matt Fleming wrote:
> 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)).

It's worth pointing out that using less than ~655 loops allows the
'sender' tasks to write down the pipes (when using -p) without
blocking due to the pipe being full, since the default number of pipe
buffers is 16 (PIPE_DEF_BUFFERS) and each buffer is one page.

This has implications for the "optimal" schedule which in that case
is: schedule all sender tasks first, and run to exit, then schedule
all readers to read from the pipes.

Just something I noticed to watch out for when picking a loops count.
There's probably some similar issue for socket buffers.