Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1517838889.6939.16.camel@gmx.de>
Subject: Re: [RESEND RFC PATCH V3] sched: Improve scalability of
 select_idle_sibling using SMT balance
From:   Mike Galbraith <efault@gmx.de>
To:     Peter Zijlstra <peterz@infradead.org>,
        Steven Sistare <steven.sistare@oracle.com>
Cc:     subhra mazumdar <subhra.mazumdar@oracle.com>,
        linux-kernel@vger.kernel.org, mingo@redhat.com,
        dhaval.giani@oracle.com
Date:   Mon, 05 Feb 2018 14:54:49 +0100
In-Reply-To: <20180205124854.GX2269@hirez.programming.kicks-ass.net>
References: <20180129233102.19018-1-subhra.mazumdar@oracle.com>
         <20180201123335.GV2249@hirez.programming.kicks-ass.net>
         <911d42cf-54c7-4776-c13e-7c11f8ebfd31@oracle.com>
         <20180202195943.GR2269@hirez.programming.kicks-ass.net>
         <25d67bd2-cbe7-2c2a-e89a-13a7ca5adc10@oracle.com>
         <20180205124854.GX2269@hirez.programming.kicks-ass.net>
Content-Type: text/plain; charset="ISO-8859-15"
Mime-Version: 1.0
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 2018-02-05 at 13:48 +0100, Peter Zijlstra wrote:
> On Fri, Feb 02, 2018 at 04:06:32PM -0500, Steven Sistare wrote:
> > On 2/2/2018 2:59 PM, Peter Zijlstra wrote:
> 
> > > But then you get that atomic crud to contend on the cluster level, which
> > > is even worse than it contending on the core level.
> > 
> > True, but it can still be a net win if we make better scheduling decisions.
> > A saving grace is that the atomic counter is only updated if the cpu
> > makes a transition from idle to busy or vice versa.
> 
> Which can still be a very high rate for some workloads. I always forget
> which, but there are plenty workloads that have very frequenct very
> short idle times. Mike, do you remember what comes apart when we take
> out the sysctl_sched_migration_cost test in idle_balance()?

Used to be anything scheduling cross-core heftily suffered, ie pretty
much any localhost communication heavy load. ?I just tried disabling it
in 4.13 though (pre pti cliff), tried tbench, and it made zip squat
difference. ?I presume that's due to the meanwhile added this_rq->rd-
>overload and/or?curr_cost checks. ?I don't recall the original cost
details beyond it having been "a sh*tload".

	-Mike