Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp5944879imm; Mon, 23 Jul 2018 08:42:13 -0700 (PDT) X-Google-Smtp-Source: AAOMgpe72+itxOcAGLcKqrB66xwzvZwcIVS9TAypwq9fDdqz0yctAbvNUKnFG1N/PGtOZG60lbTF X-Received: by 2002:a65:4c87:: with SMTP id m7-v6mr12541556pgt.98.1532360533439; Mon, 23 Jul 2018 08:42:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1532360533; cv=none; d=google.com; s=arc-20160816; b=wp2HJvYvhlPm8lG/ZFtqA0uv7vnJAaFNnH0Wfhyg/UzFe+tjUuP1W7k9YqxTHSCa1M k/UxyDnKtRE9H1p6C0NqUm0/4kmQJjxkl1YMbwPedwFdS4+Gr4Hs9kx73JgyOfA+Q0km sHqZwvdjijfqDuX9BD5eitCfUmYm2YJIsOU7+2eIEb7qbgK6r0K0RRInIOdA6mNH8o2U w1rIJhK7gWiSF+/ReQDOCxRnV+sfXxQD7F1Mn2nd7aovxuTr9OWAvhmqiPfH5/haY1E6 xSoXP9eiBXePBh2oBE0J7yidUimcddNKGQ4dyfs8j5c7bMFaKewBzNr4u8RPE0qMXRLz cDsw== 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:arc-authentication-results; bh=zJTFKSsy/KnmJWvimqg66hyB0J/yS8Ezv1amRy0Qkkg=; b=yAf/K/QGuDzf/bPKYa5jaKKTTRNjAR0byCqYrZ4yY9Bf4ds6J4tJ7tMSfIskj+ZxuK xVf6IWnhBV0Cg1ysNyOL0jBMsKOm2C5dZ0b2l96yfmSJyVNNniReZjvlig2Ta/EiKaIM N013sL8ozkrA2S++fLpjE8iLkh6JNMzjql57YToNvn4US6X3bEv9VgFQm1xSJZB/Mz/T kXpBW9vM+IMraGTJsfmcBSeSrkV+J0P5oEbcniCCrbaIkKoXffRk02lsd6sPFr47PIC+ ivSu3W5lhMfy+N0lzdZfBj8lU6/8XzDLN/QXhK1ThNbibhbYpwews0QYgyHLbER1H/Q6 UnGQ== 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 f62-v6si9514951pfa.73.2018.07.23.08.41.58; Mon, 23 Jul 2018 08:42:13 -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 S2388638AbeGWQmS (ORCPT + 99 others); Mon, 23 Jul 2018 12:42:18 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:35908 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388144AbeGWQmS (ORCPT ); Mon, 23 Jul 2018 12:42:18 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 682E380D; Mon, 23 Jul 2018 08:40:30 -0700 (PDT) Received: from e110439-lin (e110439-lin.Emea.Arm.com [10.4.12.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BD7143F237; Mon, 23 Jul 2018 08:40:27 -0700 (PDT) Date: Mon, 23 Jul 2018 16:40:25 +0100 From: Patrick Bellasi To: Suren Baghdasaryan Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Subject: Re: [PATCH v2 10/12] sched/core: uclamp: use TG's clamps to restrict Task's clamps Message-ID: <20180723154025.GF2683@e110439-lin> References: <20180716082906.6061-1-patrick.bellasi@arm.com> <20180716082906.6061-11-patrick.bellasi@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21-Jul 20:05, Suren Baghdasaryan wrote: > On Mon, Jul 16, 2018 at 1:29 AM, Patrick Bellasi > wrote: > > When a task's util_clamp value is configured via sched_setattr(2), this > > value has to be properly accounted in the corresponding clamp group > > every time the task is enqueued and dequeued. When cgroups are also in > > use, per-task clamp values have to be aggregated to those of the CPU's > > controller's Task Group (TG) in which the task is currently living. > > > > Let's update uclamp_cpu_get() to provide aggregation between the task > > and the TG clamp values. Every time a task is enqueued, it will be > > accounted in the clamp_group which defines the smaller clamp between the > > task specific value and its TG value. > > So choosing smallest for both UCLAMP_MIN and UCLAMP_MAX means the > least boosted value and the most clamped value between syscall and TG > will be used. Right > My understanding is that boost means "at least this much" and clamp > means "at most this much". Right > So to satisfy both TG and syscall requirements I think you would > need to choose the largest value for UCLAMP_MIN and the smallest one > for UCLAMP_MAX, meaning the most boosted and most clamped range. > Current implementation choses the least boosted value, so > effectively one of the UCLAMP_MIN requirements (either from TG or > from syscall) are being ignored... Could you please clarify why > this choice is made? The TG values are always used to specify a _restriction_ on task-specific values. Thus, if you look or example at the CPU mask for a task, you can have a task with affinity to CPUs 0-1, currently running on a cgroup with cpuset.cpus=0... then the task can run only on CPU 0 (althought its affinity includes CPU1 too). Same we do here: if a task has util_min=10, but it's running in a cgroup with cpu.util_min=0, then it will not be boosted. IOW, this allows to implement a "nice" policy at task level, where a task (via syscall) can decide to be less boosted with respect to its group but never more boosted. The same task can also decide to be more clamped, but not less clamped then its current group. [...] > > @@ -982,18 +989,30 @@ static inline void uclamp_cpu_get_id(struct task_struct *p, > > int clamp_value; > > int group_id; > > > > - /* No task specific clamp values: nothing to do */ > > group_id = p->uclamp[clamp_id].group_id; > > + clamp_value = p->uclamp[clamp_id].value; > > +#ifdef CONFIG_UCLAMP_TASK_GROUP > > + /* Use TG's clamp value to limit task specific values */ > > + if (group_id == UCLAMP_NONE || > > + clamp_value >= task_group(p)->uclamp[clamp_id].value) { > > Not a big deal but do you need to override if (clamp_value == > task_group(p)->uclamp[clamp_id].value)? Maybe: > - clamp_value >= task_group(p)->uclamp[clamp_id].value) { > + clamp_value > task_group(p)->uclamp[clamp_id].value) { Good point, yes... the override is not really changing anything here. Will fix this! > > + clamp_value = task_group(p)->uclamp[clamp_id].value; > > + group_id = task_group(p)->uclamp[clamp_id].group_id; > > + } > > +#else > > + /* No task specific clamp values: nothing to do */ > > if (group_id == UCLAMP_NONE) > > return; > > +#endif > > > > /* Reference count the task into its current group_id */ > > uc_grp = &rq->uclamp.group[clamp_id][0]; > > uc_grp[group_id].tasks += 1; > > > > + /* Track the effective clamp group */ > > + p->uclamp_group_id[clamp_id] = group_id; > > + > > /* Force clamp update on idle exit */ > > uc_cpu = &rq->uclamp; > > - clamp_value = p->uclamp[clamp_id].value; > > if (unlikely(uc_cpu->flags & UCLAMP_FLAG_IDLE)) { > > if (clamp_id == UCLAMP_MAX) > > uc_cpu->flags &= ~UCLAMP_FLAG_IDLE; [...] -- #include Patrick Bellasi