From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 249F8C07E94 for ; Fri, 4 Jun 2021 16:08:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0555A61402 for ; Fri, 4 Jun 2021 16:08:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229881AbhFDQKb (ORCPT ); Fri, 4 Jun 2021 12:10:31 -0400 Received: from foss.arm.com ([217.140.110.172]:42216 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229675AbhFDQKa (ORCPT ); Fri, 4 Jun 2021 12:10:30 -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 978B51063; Fri, 4 Jun 2021 09:08:43 -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 974DC3F73D; Fri, 4 Jun 2021 09:08:41 -0700 (PDT) Date: Fri, 4 Jun 2021 17:08:39 +0100 From: Qais Yousef To: Xuewen Yan Cc: Quentin Perret , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel , Chunyan Zhang , Ryan Y , Patrick Bellasi , tj@kernel.org Subject: Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max Message-ID: <20210604160839.2op4ak75vle3gmt3@e107158-lin.cambridge.arm.com> References: <20210602123803.15738-1-xuewen.yan94@gmail.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 06/03/21 10:24, Xuewen Yan wrote: > +CC Qais Thanks for the CC :) > > > Hi Quentin > > On Wed, Jun 2, 2021 at 9:22 PM Quentin Perret wrote: > > > > +CC Patrick and Tejun > > > > On Wednesday 02 Jun 2021 at 20:38:03 (+0800), Xuewen Yan wrote: > > > From: Xuewen Yan > > > > > > When setting cpu.uclamp.min/max in cgroup, there is no validating > > > like uclamp_validate() in __sched_setscheduler(). It may cause the > > > cpu.uclamp.min is bigger than cpu.uclamp.max. > > > > ISTR this was intentional. We also allow child groups to ask for > > whatever clamps they want, but that is always limited by the parent, and > > reflected in the 'effective' values, as per the cgroup delegation model. As Quentin said. This intentional to comply with cgroup model. See Limits and Protections sections in Documentation/admin-guide/cgroup-v2.rst Specifically "all configuration combinations are valid" So user can set cpu.uclamp.min higher than cpu.uclamp.max. But when we apply the setting, cpu.uclamp.min will be capped by cpu.uclamp.max. I can see you found the cpu_util_update_eff() logic. > > It does not affect the 'effective' value. That because there is > protection in cpu_util_update_eff(): > /* Ensure protection is always capped by limit */ > eff[UCLAMP_MIN] = min(eff[UCLAMP_MIN], eff[UCLAMP_MAX]); > > When users set the cpu.uclamp.min > cpu.uclamp.max: > cpu.uclamp.max = 50; > to set : cpu.uclamp.min = 60; > That would make the uclamp_req[UCLAMP_MIN].value = 1024* 60% = 614, > uclamp_req[UCLAMP_MAX].value = 1024* 50% = 512; > But finally, the uclamp[UCLAMP_MIN].value = uclamp[UCLAMP_MAX].value > = 1024* 50% = 512; > > Is it deliberately set not to validate because of the above? Sorry I'm not following you here. What code paths were you trying to explain here? Did you actually hit any problem here? Thanks -- Qais Yousef