Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp6746339ybi; Mon, 8 Jul 2019 08:00:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqwIPkRbOJAd3iHBxFdn9nqDthMIHca+XVWjCRE30ZO+pEZgJEWFSyC4GhJDsn277kdj8hNJ X-Received: by 2002:a17:90b:8cd:: with SMTP id ds13mr24984899pjb.141.1562598059568; Mon, 08 Jul 2019 08:00:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562598059; cv=none; d=google.com; s=arc-20160816; b=aorut0ogFmNeBME3utG3EESeENJdp0ueXPEvM5oVFieuw5XvVBK8S9UXeImRwXW6Rf WVG8ZyYXxfMsvETltI5SCfnsOYtGwrUfiVC6DAX+EqqSf7ufSneRozjBRUTnb6l32s4l /kbhjbqlobw6af23t4UBlYaMfv9s+1CvpBLko+oeJQ0LW7k82Eg7wtXmjTdTVvIHc/a+ O6bwlUJDEG6sn5o1thopX4ducCr7cFhWPDjYpS3g8VQtxGSsimd0rpc1ErYG9bigIxSa /swmoJLW4CDaZkCYku43tN8OQgZgMQpUzu2dFd24pJC432U3Fh2lTAD/WtJY5GrRvNrd v+iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=HtIlPZbiZh23X5EjCpaTdG+gnXoe7ngoJ64ym0tFfH0=; b=s51wdsoKPLhVf+9Uq8CCEFM7SP9JoW6SSzyr6484Qo6jJhCTJLpVHMHAHf9xlgcQ8h JkMS6/pEMiG1bq00VtVPFP/aR/J04MPrjuRfukiQKjxFfTZvJSHFCP1nrRnKVRAHV8B9 C5ytFNwVly/hyyUVNmYmZKCQVrrRwJJA9GFecrb1t1zJFzOX7uF/x3d3mLbFikz0OVUq 4qsEZUf8M9r3HLjO+yt5iZ7c3cjJsI4kwoYa1EvgbPFlORoJDTeZnY47s7E9sm7U6wNb 86WTNheGFoxlQCsAzdonZ3wST9253+WGAKkPB8tHd9zHN9LBHprmeG+QsMZzDs8z4lx8 BK+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z142si19430569pfc.128.2019.07.08.08.00.43; Mon, 08 Jul 2019 08:00:59 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728889AbfGHLIu (ORCPT + 99 others); Mon, 8 Jul 2019 07:08:50 -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