Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp4896651pxu; Tue, 13 Oct 2020 09:35:25 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzvEiKTpMTDcHn0/9jrCc3GGxRcUu79a5e0RAwPPUGE1e/HUTEmH+Y9mhDNuF92CIOdyUWt X-Received: by 2002:a17:906:4b0f:: with SMTP id y15mr596813eju.198.1602606925011; Tue, 13 Oct 2020 09:35:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602606925; cv=none; d=google.com; s=arc-20160816; b=OAO61nuqnCDsChDOGflhIAVMXSXRXw7ok4iTuGfOFu9o5Qjqid4zIVBBGNe3hkO29X X7k7BR7mz+HYGm8FbXbIJw6OSDdKcIoV3+py1cdbQzQvbDQtMzgNbsBIDMX2j6q03zSY Hsoe4NAPrn+8IYK44VXJNF/mXgnPJ3xmsFbB0rZR0Bij/llhFsQokh9X0B8Io4zoN45T AYeGCDK8s7z+XpVJetUK/VFaevJG22+gJljCaY3BmKyuQYlQHqGH316kf8c8OG7oSAMg 2w8OiF5FhiHSs1AziQd2qEEVhHBYL4edYij4CgyVaejB/CPaxZLkhUKGq3t1wX3OI3X9 dc8w== 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=/GtzXhhuWZEKQ4x4gWGNGA4RUtQnuHdtAdPovlHyBPM=; b=HgAgnYzUDoAxtpDA7x6AUw+AVc9uwJM8jpwrjVt/XGZOZaQdjsTjmB0PIq9Y8ET4zE uEPZoJtj9+j4yUueGML1SlIgI88/KHMyu+2KEO6ekhNF1Bsf40zzn9eViG3pdg/3QwTe f7/1qvisEJwFoH8H/NZ4/47tWsmhujIPYYAVy82IMdXnmNnR9FJkVz4ja0c8OkrIWcjP svejzpyj6bileZ2tpOchMs9QlKbJmLSo8sG8LFai9x66xGFk6/4GirIIG9V/qgjzCcub HawR0aCV+OXdTFEcjT+LVchdHtMZVtOc2k/TVaYDyMP6GQzAhND0R9G0+TOwfoyl/Evl 2rtw== 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 e21si146915edr.78.2020.10.13.09.35.01; Tue, 13 Oct 2020 09:35:24 -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 S1728629AbgJMNcu (ORCPT + 99 others); Tue, 13 Oct 2020 09:32:50 -0400 Received: from foss.arm.com ([217.140.110.172]:59998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727448AbgJMNcu (ORCPT ); Tue, 13 Oct 2020 09:32:50 -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 203771FB; Tue, 13 Oct 2020 06:32:50 -0700 (PDT) Received: from e107158-lin (e107158-lin.cambridge.arm.com [10.1.194.78]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 55BB03F719; Tue, 13 Oct 2020 06:32:49 -0700 (PDT) Date: Tue, 13 Oct 2020 14:32:46 +0100 From: Qais Yousef To: Patrick Bellasi Cc: Yun Hsiang , dietmar.eggemann@arm.com, peterz@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/1] sched/uclamp: add SCHED_FLAG_UTIL_CLAMP_RESET flag to reset uclamp Message-ID: <20201013133246.cjomufo5q7qsocrn@e107158-lin> References: <20201012163140.371688-1-hsiang023167@gmail.com> <87blh6iljc.derkling@matbug.net> <20201013102951.orcr6m4q2cb7y6zx@e107158-lin> <875z7eic14.derkling@matbug.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <875z7eic14.derkling@matbug.net> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/13/20 13:46, Patrick Bellasi wrote: > > So IMO you just need a single SCHED_FLAG_UTIL_CLAMP_RESET that if set in the > > attr, you just execute that loop in __setscheduler_uclamp() + reset > > uc_se->user_defined. > > > > It should be invalid to pass the SCHED_FLAG_UTIL_CLAMP_RESET with > > SCHED_FLAG_UTIL_CLAMP_MIN/MAX. Both have contradictory meaning IMO. > > If user passes both we should return an EINVAL error. > > Passing in _CLAMP_RESET|_CLAMP_MIN will mean reset the min value while > keeping the max at whatever it is. I think there could be cases where > this support could be on hand. I am not convinced personally. I'm anxious about what this fine grained control means and how it should be used. I think less is more in this case and we can always relax the restriction (appropriately) later if it's *really* required. Particularly the fact that this user_defined is per uclamp_se and that it affects the cgroup behavior is implementation details this API shouldn't rely on. A generic RESET my uclamp settings makes more sense for me as a long term API to maintain. Actually maybe we should even go for a more explicit SCHED_FLAG_UTIL_CLAMP_INHERIT_CGROUP flag instead. If we decide to abandon the support for this feature in the future, at least we can make it return an error without affecting other functionality because of the implicit nature of SCHED_FLAG_UTIL_CLAMP_RESET means inherit cgroup value too. That being said, I am not strongly against the fine grained approach if that's what Yun wants now or what you both prefer. I just think the name of the flag needs to change to be more explicit too then. It'd be good to hear what others think. Cheers -- Qais Yousef