Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1002522ybt; Fri, 19 Jun 2020 21:14:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzagdxkB/o0v3ocrgSl6kD+IUnTIDtfb9dmR/vr/e3si6dcaSGYyySznWMTOQ0jQFetutMu X-Received: by 2002:a17:906:5fcd:: with SMTP id k13mr6337417ejv.459.1592626457731; Fri, 19 Jun 2020 21:14:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592626457; cv=none; d=google.com; s=arc-20160816; b=jzKL8ec6d5AGNNm2Ef6jkyLMuNnDHnBNoZit23Z2DY/RpxcOqR/6iewrsLVUc0B9Sp ttQ1x7qjbeRjPGOuhyABnO0yDFI6mBK6CtrQfD/uTFfDVtdcJnFHsGv4boOb/3eyzrcu q29VnupasymWYUJO2L3rgpCqZAQtACGfJkew483M3ZdsyJ75ZTxczEkaSV86e8c1l/r6 +dtiBxnJ9M+UfTJEmcFJG2Z6bNxBA2OrLsrPvxG8/ZVEbcV5eCkbJeD+G+tjTePDVFHo yBBu/+TMc/OFSYvAT0eHM1v+0HVaHK6WLFlRipuycoCj/8SJOUteIvFxun9U60sJttKi 6sNg== 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=u1f7iVdJ6/6FhzUbfxsq6/qUdQ3NDoxJSGZveqsVYAo=; b=wF1Pyy+M4oOP/sh8J6zeYyGEAGBVkXsf7F1/XGmOrkCS70c+lC0TDyG3jvexcmCwmK CkweZNYVsMJrQ/sPgRXZ9FDF4PDZNzMS8X0kbP5JuERn8Xdhk/hHAnEjo0ykuprRoAcU oSrc7fyQDhElGdALZXuQV/GpFHQ1TA/CkYEQPT3vE9z1LY6UvZhBdRygczzmxv4rAz5o LWT9HybXNhV3xLviZ4zk5obMS1ZNGOMDF8+YdIROJaBYW9e3j5G9rAYnN8JOB3RDDr89 nnbwI0atkVdJFzZDofDZjHvH3ncSJ/teMP0erZHpOqv3XcSzM84kIpDJeqHh6mVb8l1F pfjQ== 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 a24si5887359edm.17.2020.06.19.21.13.55; Fri, 19 Jun 2020 21:14:17 -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 S2392298AbgFSRZa (ORCPT + 99 others); Fri, 19 Jun 2020 13:25:30 -0400 Received: from foss.arm.com ([217.140.110.172]:49546 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731175AbgFSRZ3 (ORCPT ); Fri, 19 Jun 2020 13:25:29 -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 26B9DD6E; Fri, 19 Jun 2020 10:25:29 -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 78B443F71F; Fri, 19 Jun 2020 10:25:27 -0700 (PDT) Date: Fri, 19 Jun 2020 18:25:25 +0100 From: Qais Yousef To: Valentin Schneider Cc: Ingo Molnar , Peter Zijlstra , 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: <20200619172524.y66a4hz6g6hr3thr@e107158-lin.cambridge.arm.com> References: <20200618195525.7889-1-qais.yousef@arm.com> <20200618195525.7889-3-qais.yousef@arm.com> <20200619125148.y4cq3hwllgozbutq@e107158-lin.cambridge.arm.com> <20200619141348.5o5iqomwe6lofgiu@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 16:17, Valentin Schneider wrote: [...] > > But here this is > > just extra churn. > > > > If an imbalance has happend this means either: > > > > 1. enqueue/dequeue_task() is imablanced itself > > 2. uclamp_update_active() calls dec without inc. > > > > If 1 happened we have more reasons to be worried about. For 2 the function > > takes task_rq_lock() and does dec/inc in obvious way. > > > > True. I won't argue over the feasibility of the scenarios we are currently > aware of, my point was that if they do happen, it's nice to have debug > helps in the right places as the final breakage can happen much further > downstream. > > FWIW I don't like the diff I suggested at all, but if we can come up with a > cleverer scheme I think we should do it, as per the above. There's the fact as well that this whole thing is to deal with potentially avoid doing anything that is stricly not necessary in the fast path. keep in mind that my patch of introducing the sysctl is not accepted yet because it introduces such thing, but in that case it's not a debug only feature. CONFIG_SCHED_DEBUG do get enabled by distros because it exports a lot of useful info. -- Qais Yousef