Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1004313ybt; Fri, 19 Jun 2020 21:17:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwVfAf3i1IJoD3lSC9ISerE4CI9/FKsaDHM35Q27BxW6sb7CCV6GG4xNKGUMdFwbT+6Jr44 X-Received: by 2002:a05:6402:1b01:: with SMTP id by1mr6430010edb.20.1592626676992; Fri, 19 Jun 2020 21:17:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592626676; cv=none; d=google.com; s=arc-20160816; b=izHsGj7wmbdlsaxafYoQVUuAEnCmi2YLEPIspstSgggvDreux/UB+/CT8b73TVZYIF P5gPaxCu7k/Csm59+eZ5poZ/ubcfz4Kx+0/tt4dXIgDoPkyXSpL5vpWXAe77cIt5MwNZ pO8y5D4+eqiuZ7IsBLMpasXDXWAmuNBh75B5isMlS9soYO9ZCCrgIoKi/IrUqUxUX6JO FZf63OfrCDOu9XS7h9KiLEjVmBuP85n6W1gBJmW8L0OmmBrcZJrMnSDj5Lzs4oCBogIi RtRPITs1IlSaJUP725np6C7ta9mEp2Mb/T8MsbsIDE6ymnJ8WibKQ0OKPIet6DV9r945 2GMA== 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; bh=T1y9XWWPY2Hz1lRLhWveo2J35kyYduQsLn/jNw/0WuM=; b=KAOjBCwE7z04Divl2dOp/ZPerEIUVIYaRqYsG8Gikyv2DahS4qaWjCQJtVhB8Cu9hx wwMnctpRNFS64ubor1O4dU9xYPaPBN3iq4q1rzCNCUNKg+ruzBTkO4bvdK3nYYb9Nfu9 /2mdkmMjF5utoqEuHlPCqDbyMDTLvRC0H63prkie3ZKpn6iWYQ4wLoN8YvOeDB1VauVi VksTt0Feq3m5xN1NWtnqLb2MEoDsbs28ww429LDLegVhKnES+KqCkkIZIRXmh8jyJrWf JyWKsbHTk6aip9JXrjMsFEr94X/POgzYNWCMG8sP8mlwhGkqVDjN8uQZznR+30BRLILv iYVA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c18si5229657edt.202.2020.06.19.21.17.35; Fri, 19 Jun 2020 21:17:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393643AbgFSRxG (ORCPT + 99 others); Fri, 19 Jun 2020 13:53:06 -0400 Received: from foss.arm.com ([217.140.110.172]:51680 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731445AbgFSRxF (ORCPT ); Fri, 19 Jun 2020 13:53:05 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C02972B; Fri, 19 Jun 2020 10:53:04 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3A8623F73C; Fri, 19 Jun 2020 10:53:03 -0700 (PDT) Date: Fri, 19 Jun 2020 18:53:00 +0100 From: Qais Yousef To: Peter Zijlstra Cc: Ingo Molnar , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Patrick Bellasi , Chris Redpath , Lukasz Luba , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] sched/uclamp: Protect uclamp fast path code with static key Message-ID: <20200619175300.sqqdeu6qug3ilnfd@e107158-lin.cambridge.arm.com> References: <20200618195525.7889-1-qais.yousef@arm.com> <20200618195525.7889-3-qais.yousef@arm.com> <20200619174510.GB576888@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200619174510.GB576888@hirez.programming.kicks-ass.net> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/19/20 19:45, Peter Zijlstra wrote: > On Thu, Jun 18, 2020 at 08:55:25PM +0100, Qais Yousef wrote: > > > +/* > > + * This static key is used to reduce the uclamp overhead in the fast path. It > > + * only disables the call to uclamp_rq_{inc, dec}() in enqueue/dequeue_task(). > > + * > > + * This allows users to continue to enable uclamp in their kernel config with > > + * minimum uclamp overhead in the fast path. > > + * > > + * As soon as userspace modifies any of the uclamp knobs, the static key is > > + * disabled, since we have an actual users that make use of uclamp > > + * functionality. > > + * > > + * The knobs that would disable this static key are: > > + * > > + * * A task modifying its uclamp value with sched_setattr(). > > + * * An admin modifying the sysctl_sched_uclamp_{min, max} via procfs. > > + * * An admin modifying the cgroup cpu.uclamp.{min, max} > > + */ > > +DEFINE_STATIC_KEY_TRUE(sched_uclamp_unused); > > Maybe call the thing: 'sched_uclamp_users', instead? > > > > + if (static_branch_unlikely(&sched_uclamp_unused)) > > + static_branch_disable(&sched_uclamp_unused); > > > > + if (static_branch_unlikely(&sched_uclamp_unused)) > > + static_branch_disable(&sched_uclamp_unused); > > > > + if (static_branch_unlikely(&sched_uclamp_unused)) > > + static_branch_disable(&sched_uclamp_unused); > > That's an anti-pattern... just static_branch_disable(), or _enable() > with a 'better' name is sufficient. I misread the code. I saw there's a WAN_ON_ONCE() but that only triggers if the atomic variable has a value that is ! in (0, 1) range. So yes we can call it unconditionally. Thanks -- Qais Yousef