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=-5.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 9EFC0C47425 for ; Fri, 4 Jun 2021 16:22:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 851E96140C for ; Fri, 4 Jun 2021 16:22:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231521AbhFDQYh (ORCPT ); Fri, 4 Jun 2021 12:24:37 -0400 Received: from foss.arm.com ([217.140.110.172]:42556 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230231AbhFDQYg (ORCPT ); Fri, 4 Jun 2021 12:24:36 -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 1BC601424; Fri, 4 Jun 2021 09:22:50 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A3BBA3F73D; Fri, 4 Jun 2021 09:22:47 -0700 (PDT) Subject: Re: [PATCH] sched/uclamp: Avoid setting cpu.uclamp.min bigger than cpu.uclamp.max To: Qais Yousef , Xuewen Yan Cc: Quentin Perret , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , linux-kernel , Chunyan Zhang , Ryan Y , Patrick Bellasi , tj@kernel.org References: <20210602123803.15738-1-xuewen.yan94@gmail.com> <20210604160839.2op4ak75vle3gmt3@e107158-lin.cambridge.arm.com> From: Dietmar Eggemann Message-ID: Date: Fri, 4 Jun 2021 18:22:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <20210604160839.2op4ak75vle3gmt3@e107158-lin.cambridge.arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/06/2021 18:08, Qais Yousef wrote: > 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. To support this: Patrick had appropriate checks in his `[PATCH v10 12/16] sched/core: uclamp: Extend CPU's cgroup controller`. https://lkml.kernel.org/r/20190621084217.8167-13-patrick.bellasi@arm.com But is was discussed that cgroup v2 `resource distribution model` configurations (here protection/limit: uclamp_min/uclamp_max) should not be restricted. Further down in this thread: "... Limits always trump protection in effect of course but please don't limit what can be configured..."