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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,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 4BF6DC606AF for ; Mon, 8 Jul 2019 11:08:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B37D20656 for ; Mon, 8 Jul 2019 11:08:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730376AbfGHLIv (ORCPT ); Mon, 8 Jul 2019 07:08:51 -0400 Received: from foss.arm.com ([217.140.110.172]:44916 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730358AbfGHLIs (ORCPT ); Mon, 8 Jul 2019 07:08:48 -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 F2412360; Mon, 8 Jul 2019 04:08:47 -0700 (PDT) Received: from queper01-lin (queper01-lin.cambridge.arm.com [10.1.195.48]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B7F2E3F738; Mon, 8 Jul 2019 04:08:45 -0700 (PDT) Date: Mon, 8 Jul 2019 12:08:41 +0100 From: Quentin Perret To: Patrick Bellasi Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle , Suren Baghdasaryan , Alessio Balsini Subject: Re: [PATCH v11 1/5] sched/core: uclamp: Extend CPU's cgroup controller Message-ID: <20190708110838.4ohd7pqx5ngkzcsu@queper01-lin> References: <20190708084357.12944-1-patrick.bellasi@arm.com> <20190708084357.12944-2-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190708084357.12944-2-patrick.bellasi@arm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Patrick, On Monday 08 Jul 2019 at 09:43:53 (+0100), Patrick Bellasi wrote: > +static inline int uclamp_scale_from_percent(char *buf, u64 *value) > +{ > + *value = SCHED_CAPACITY_SCALE; > + > + buf = strim(buf); > + if (strncmp("max", buf, 4)) { > + s64 percent; > + int ret; > + > + ret = cgroup_parse_float(buf, 2, &percent); > + if (ret) > + return ret; > + > + percent <<= SCHED_CAPACITY_SHIFT; > + *value = DIV_ROUND_CLOSEST_ULL(percent, 10000); > + } > + > + return 0; > +} > + > +static inline u64 uclamp_percent_from_scale(u64 value) > +{ > + return DIV_ROUND_CLOSEST_ULL(value * 10000, SCHED_CAPACITY_SCALE); > +} FWIW, I tried the patches and realized these conversions result in a 'funny' behaviour from a user's perspective. Things like this happen: $ echo 20 > cpu.uclamp.min $ cat cpu.uclamp.min 20.2 $ echo 20.2 > cpu.uclamp.min $ cat cpu.uclamp.min 20.21 Having looked at the code, I get why this is happening, but I'm not sure if a random user will. It's not an issue per se, but it's just a bit weird. I guess one way to fix this would be to revert back to having a 1024-scale for the cgroup interface too ... Though I understand Tejun wanted % for consistency with other things. So, I'm not sure if this is still up for discussion, but in any case I wanted to say I support your original idea of using a 1024-scale for the cgroups interface, since that would solve the 'issue' above and keeps things consistent with the per-task API too. Thanks, Quentin