Received: by 10.223.185.116 with SMTP id b49csp1042874wrg; Fri, 16 Feb 2018 11:21:11 -0800 (PST) X-Google-Smtp-Source: AH8x224jGEiLisHf4Q16CYAS+Nr6DaELtDySD0n1lYxa/8J7u2KnEvcHg5m0KYK4cB0H2AK2erqZ X-Received: by 10.98.212.6 with SMTP id a6mr7119548pfh.104.1518808871327; Fri, 16 Feb 2018 11:21:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518808871; cv=none; d=google.com; s=arc-20160816; b=bDZJMX+9RJ8/mWx8aNJyZLIoO7yPx5x5Q7+owQE0hlFZb1C9fW+8Nw2svMzyve68UO KuMc2nFkrjqp5vQV8fqcnTGNmpa/ly61teHSGwgWPZU0FpjvVO+Vz+nO8k5aoWJcZPUg vTqkBx6focLKikFxVD7BsYtfERkMgjk/mroznD3e7l4Evk/hWjH5dE8Jz1AmsD5cB9Mf 0OdXmA7DYKITqtwquXT491ac8QkS+d5bZ0Lm/Fon1E4uguqnvFGugyNvaV+Rx76rj1tQ owV3JvG3zNp7vHTpeUHYraVR660hQYstjm0bEggqG5K5MNxmD67lnht00tWNHYpAPME2 QJxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=zuhfsuAVyhz69yCtlkUmrKPdXyWG+6mCzAI88BVofYE=; b=VCx7qpLWE/FREJktPtFnqfFXH807IbtxGqDhH1EXu8mImviuEb+Es5j4Wc5lKTIHQ1 x0zjtBC+R/bOrnRgrndFiUjGN/UQKKfZx9N88vzKpYo8uqLfiPrxdV9toiPO0pHA1nZ0 vNBspKSFSBN1Lvs0cZWxwgo/voEbb8pDxfQelbEFjSsE9kQ5AKMiVHCdSdnu/J+Usk8+ 55GXspMa6/B+AR+I3WzroBQR14O7+9WuItdJ+AwM1VnX4TO3IMZIjbZQw2B8rM0G7RUj oe2FmpLuor2DiGSUEZLId/DsFtPsI+iSi19Xta7wcZT4xi3Ju9VftZL5KXKTg53gTvhT ohGg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m6-v6si1355492plt.785.2018.02.16.11.20.56; Fri, 16 Feb 2018 11:21:11 -0800 (PST) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162238AbeBPRjg (ORCPT + 99 others); Fri, 16 Feb 2018 12:39:36 -0500 Received: from foss.arm.com ([217.140.101.70]:42430 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162052AbeBPRjf (ORCPT ); Fri, 16 Feb 2018 12:39:35 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7EFDA80D; Fri, 16 Feb 2018 09:39:34 -0800 (PST) Received: from e108498-lin.cambridge.arm.com (e108498-lin.cambridge.arm.com [10.1.210.27]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 060D63F53D; Fri, 16 Feb 2018 09:39:32 -0800 (PST) Date: Fri, 16 Feb 2018 17:39:27 +0000 From: Quentin Perret To: Morten Rasmussen Cc: Peter Zijlstra , Morten Rasmussen , mingo@redhat.com, valentin.schneider@arm.com, dietmar.eggemann@arm.com, vincent.guittot@linaro.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] sched: Add static_key for asymmetric cpu capacity optimizations Message-ID: <20180216173927.GA5352@e108498-lin.cambridge.arm.com> References: <1518711654-23503-1-git-send-email-morten.rasmussen@arm.com> <1518711654-23503-2-git-send-email-morten.rasmussen@arm.com> <20180216134704.GE25201@hirez.programming.kicks-ass.net> <20180216154101.GE28799@e105550-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180216154101.GE28799@e105550-lin.cambridge.arm.com> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Morten, On Friday 16 Feb 2018 at 15:41:01 (+0000), Morten Rasmussen wrote: > On Fri, Feb 16, 2018 at 02:47:04PM +0100, Peter Zijlstra wrote: > > On Thu, Feb 15, 2018 at 04:20:48PM +0000, Morten Rasmussen wrote: > > > +static void update_asym_cpucapacity(int cpu) > > > +{ > > > + if (!static_branch_unlikely(&sched_asym_cpucapacity) && > > > + lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY)) > > > + static_branch_enable(&sched_asym_cpucapacity); > > > +} > > > > That looks odd, why not just: > > > > if (lowest_flag_domain(cpu, SD_ASYM_CPUCAPACITY)) > > static_branch_enable(&sched_asym_cpucapacity); > > I actually had that initially and then I misread the implementation of > static_key_enable() as if it trigger the WARN_ON_ONCE() condition if I > enable an already enabled static key. But I see now that it should be > safe to do. AFAIU it should be safe, but without your check you'll have to go through cpus_read_lock()/unlock() every time a CPU is hotplugged. There is probably no good reason to re-do that again and again if the state of the key never changes. I don't know how expensive those lock/unlock operations are, but I bet they are more expensive than testing static_branch_unlikely() :) > > > ? possibly with: > > > > else > > static_branch_disable(&sched_asym_cpucapacity); > > > > if you want to play funny games :-) > > I thought about that too. It could make certain hotplug scenarios even > more expensive. I think we want the sched_asym_cpucapacity code to behave > even if SD_ASYM_CPUCAPACITY isn't set anywhere, so the static key would > be permanently from the point we detect asymmetry and leave it set. This > would be in line with how the smt static key works. Thanks ! Quentin