Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp883045pxv; Thu, 1 Jul 2021 11:27:45 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxI97Z7JRidggzXYPPU6FKl/KQp/RsSGgxmRHf7durZ+U709E3ovw0Zos6ldR/YmQnV489Z X-Received: by 2002:a5e:a612:: with SMTP id q18mr596784ioi.76.1625164065042; Thu, 01 Jul 2021 11:27:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625164065; cv=none; d=google.com; s=arc-20160816; b=nuA+9muTAbgKwypQoVhAL4KqKaYj3mT9plJlKWXbNQvutm3Ez9K9djUL1f2LMz/hpC O910BenLcfHFWS+o1pDdA8sug99rvt9vvf1+GcWZ8EIgsFlc4Bw1gWecs4rK2ERLYFOR KVAaN5/hw+QvgR9DPazqMlfPxxPDAp7lTELtzuDC/u9mPuTyx9yjRcUkF9FXhac7DSrl rNqhmtSBvFShmPEJ6ev0tATTdBu/bxo3cZlIk0pJQpMKrpSQYBrd8TkelG5RMVDdN4dk dFuzPwUVTMpjc68m5PYtVdnh+HlYRz+8WpcJAVRZqcNaxyCRqDHJ4TXH1PsurlnAG8JS ZTQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=fWeDx/e2AUcATk2lL7r5pKOtg4NyqudZdtg4tNNhKH8=; b=wV7NRpXOak3+oDL/PS+PVXsC9jTyGVERjQjQuL4bR2RGGnvKgMeJXsV3k/QfVsMccJ Llr6BV9hOD0D9LzomqWWp8afKbZ3D2n59o9Zxf9EGpy0b72EfA1Zkh92FtO46XBVoe09 ueXqedIMR6JxxeC64tOEuNCSMUaMLsTRENzza0M8T2zdzdB25waFoTFAeoaGGIPlqRFr wb3DS67QA8ElNXtiKiKLv1YA7Y0RU5fYBT+hSxlwszw+w4ANRWulpsMoj/cqeph36Qj9 COVIYwF4BR1hUMRIwPsgkptx44Ke/i3cLUMN8ZdHX3ybpGYTTE7cdgKFBnBKvkBPvq9t vF9A== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t17si504568ilp.132.2021.07.01.11.27.32; Thu, 01 Jul 2021 11:27:45 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232301AbhGASCH (ORCPT + 99 others); Thu, 1 Jul 2021 14:02:07 -0400 Received: from foss.arm.com ([217.140.110.172]:59016 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbhGASCH (ORCPT ); Thu, 1 Jul 2021 14:02:07 -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 39D026D; Thu, 1 Jul 2021 10:59:36 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.57]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C2A8C3F5A1; Thu, 1 Jul 2021 10:59:34 -0700 (PDT) Date: Thu, 1 Jul 2021 18:59:32 +0100 From: Qais Yousef To: Quentin Perret Cc: mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rickyiu@google.com, wvw@google.com, patrick.bellasi@matbug.net, xuewen.yan94@gmail.com, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v3 1/3] sched: Fix UCLAMP_FLAG_IDLE setting Message-ID: <20210701175932.66hiwvuia4drs4yl@e107158-lin.cambridge.arm.com> References: <20210623123441.592348-1-qperret@google.com> <20210623123441.592348-2-qperret@google.com> <20210630145848.htb7pnwsl2gao77x@e107158-lin.cambridge.arm.com> <20210701110803.2lka3eaoukbb6b4p@e107158-lin.cambridge.arm.com> <20210701145750.7mqat4ehja7ikbtc@e107158-lin.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07/01/21 15:20, Quentin Perret wrote: > > > Right or maybe we can just check that uclamp_id == UCLAMP_MAX here and > > > we should be good to go? That is, what about the below? > > > > Wouldn't it be better to do this from uclamp_idle_reset() then? > > That should work too, but clearing the flag outside of > uclamp_rq_inc_id() feels a little bit more robust to ordering > issues. > > Specifically, uclamp_rq_inc() has the following pattern: > > for_each_clamp_id(clamp_id) > uclamp_rq_inc_id(rq, p , clamp_id); > > if (rq->uclamp_flags & UCLAMP_FLAG_IDLE) > rq->uclamp_flags &= ~UCLAMP_FLAG_IDLE; > > So, if we change this to clear the flag from > uclamp_rq_inc_id()->uclamp_idle_reset() then we'll have issues if > (for example) for_each_clamp_id()'s order changes in the future. > IOW, it feels cleaner to not create side effects in uclamp_rq_inc_id() > that impact the idle flag given that its very own behaviour depends on > the flag. > > WDYT? Do the clearing from outside the loop then to keep the pattern consistent? Anyway, I think there's no clear objective advantage. So I'll trust your judgement and promise not to complain with your final choice ;-) Cheers -- Qais Yousef