From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754408AbdK2KmA (ORCPT ); Wed, 29 Nov 2017 05:42:00 -0500 Received: from mail-lf0-f65.google.com ([209.85.215.65]:33427 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752495AbdK2Kl5 (ORCPT ); Wed, 29 Nov 2017 05:41:57 -0500 X-Google-Smtp-Source: AGs4zMaJXjRxTCjdfOVY9E3fygggow0dfwbV4oKvBiYTpB2+mqatG/HiWDbJ2iRAexqfWeXdD0dGvA== From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 29 Nov 2017 11:41:47 +0100 To: Mike Galbraith Cc: Uladzislau Rezki , Atish Patra , Peter Zijlstra , Joel Fernandes , LKML , Brendan Jackman , Josef Bacik , Ingo Molnar Subject: Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window. Message-ID: <20171129104147.dcc25xv64o4bwdyv@pc636> References: <1509427662-25114-2-git-send-email-atish.patra@oracle.com> <20171031082009.rxxa57goto6q5xld@hirez.programming.kicks-ass.net> <49e98b00-80c7-b3a4-30fd-bccb382d002b@oracle.com> <20171123105247.wcl2fiypge2pvile@pc636> <1511442781.6505.26.camel@gmx.de> <20171124102636.zqqjqa3sru7ebh4k@pc636> <1511549190.8029.233.camel@gmx.de> <20171128093422.5hmrkonj3z6twy2y@pc636> <1511866151.8472.51.camel@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1511866151.8472.51.camel@gmx.de> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 28, 2017 at 11:49:11AM +0100, Mike Galbraith wrote: > On Tue, 2017-11-28 at 10:34 +0100, Uladzislau Rezki wrote: > > On Fri, Nov 24, 2017 at 07:46:30PM +0100, Mike Galbraith wrote: > > > > > My view is you're barking up the wrong tree: you're making the idle > > > data SIS is using more accurate, but I question the benefit.  That it > > > makes an imperfect placement decision occasionally due to raciness is > > > nearly meaningless compared to the cost of frequent bounce. > > > Before sitting down and start testing, i just illustrated how we can > > apply claim_wake_up to ilb asking community a specific view on it: > > drawbacks, pros/cons, proposals etc. > > Even if you make the thing atomic, what is ILB supposed to do, look > over its shoulder every step of the way and sh*t it's pants if somebody > touches claim_wake_up as it's about to or just after it did something? If nohz.idle_cpus_mask is set for particular CPU together with claim mask, it means that TIF_NEED_RESCHED is coming or is already in place. When a CPU hits idle_thread a claim bit gets reset and proceed to no_hz mode unless it runs into scheduler_ipi or so. > > If you intend to make all of LB race free, good luck. > > -Mike Vlad