Received: by 10.223.185.116 with SMTP id b49csp1039155wrg; Fri, 16 Feb 2018 11:16:37 -0800 (PST) X-Google-Smtp-Source: AH8x227N5B39Igh4IDsJznhHACY0vX+rTZOKsL/AYtRTtQcWxs4yg9it+058sSpVTpkckL6LLIdi X-Received: by 10.101.96.212 with SMTP id r20mr5939271pgv.139.1518808597780; Fri, 16 Feb 2018 11:16:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518808597; cv=none; d=google.com; s=arc-20160816; b=YNuRSBeCNts5OR1ihT6jxGsGxFgYkhJxK/1RPkaVIzqq0rPVLyNKJsDPqGVd1yhbt4 NKmBcDhfRvMAmEd4dCH4GtFA6edol6uotkcPNlEXEqoaQbMSp7k5OD1u55ykalRUc5xk 8zxBZnqxCSJ9GHkdsLv1ie/A/27MP6kDZdh0+dHgV2dX3T4Xe1giCHVcASUe014mJILb GQlWf4e5MZShLmpIn0PMsVOChvF7ymq17THlN39USJU69uQ0nfYvBtDg1b9f6+8uGnlB DuIP9WA341OmBofztsB+cLzxtcO5Bbqhapn3SxjELMeT7vqdxVHxpMtYXUiViT1cxM6u FIFQ== 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=mqQrRZrsvuHG1hkUrB39e7a3sdaakV3tg2f1C6ZB8ko=; b=OK7JRQWrFlgukeOGgeN4t6jAT45StiLxCFZ5vRgMUqtPw1R6h4v1fSz+uxRg0+Qpjg 0Jxh5bdzANLe1ivIW6dyvxuDuxp3h9Kgq7+o2R/A3F02PC0GAzwP1w+jnG0ublYzYFJm s4H3mDFgF4nO1nrFZ8hd6VtWDf/uj/8SfEr7ZXJNNi0TVmAEuXif0W2a+2E0WlZvBwXo fAIa8qBja2LJGAcv8XkeIsogsSNjMt4Pa9JX3gPodSmUHhwmsIbrI+QHGzW8S2+wiD2n NQqNLV3yM/ZU+gIeFMBoTkpekmjMSwNIlfcasrpqbYUWzjd6fSp3RNIb/HJRk4YFEaJw Qz5Q== 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 c11-v6si3508650plr.611.2018.02.16.11.16.23; Fri, 16 Feb 2018 11:16:37 -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 S1756530AbeBPPlI (ORCPT + 99 others); Fri, 16 Feb 2018 10:41:08 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:41118 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756467AbeBPPlF (ORCPT ); Fri, 16 Feb 2018 10:41:05 -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 82B2D1435; Fri, 16 Feb 2018 07:41:05 -0800 (PST) Received: from e105550-lin.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2D4693F24D; Fri, 16 Feb 2018 07:41:04 -0800 (PST) Date: Fri, 16 Feb 2018 15:41:01 +0000 From: Morten Rasmussen To: Peter Zijlstra Cc: 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: <20180216154101.GE28799@e105550-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180216134704.GE25201@hirez.programming.kicks-ass.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > ? 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.