Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp599812img; Mon, 18 Mar 2019 10:00:11 -0700 (PDT) X-Google-Smtp-Source: APXvYqytgW7Nq3OzzpIRTXldlS0OiQwKxl1ZHI962DBv7pyCE4rmiOyk5CTMHnHTtNvBB8ju2Avs X-Received: by 2002:a62:ea08:: with SMTP id t8mr19928706pfh.60.1552928411190; Mon, 18 Mar 2019 10:00:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552928411; cv=none; d=google.com; s=arc-20160816; b=Xpg4gFBtkIWwAju/lWkSeoSeirsPkvpHcex3VaCKGWghY+WduHcDVA5Xm/6ZOofskE tHEmmvTGt2Knbf6Z6yF/T7PY/jzCkqDzhN+JcZmvVGzyxW7j8LTttCtQuK0WTV25xAch QjxUlOj6IyvELr+ZZhudtzbtkTTjTSdD2XIZ1AWIPo2QmySXMkM7dtK1d2mHDsoYkhCz uLPzHC0cdBYNnTsuN+3W5A7SwtUZ1hnYrI8yRsErUWp0SMnDb57MSZVCpGEgvKfQNNw9 VFDO9ciBDCwznkAqR5iEZ93kWE/Hs283SBNfDFLl540EKhO6+b7zi1h+/09tz7NDUMjB 9x5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TCSjK1Dk6w+M0CcBcRsq6gEkd5BO241ZrrOfpC+KdRY=; b=i4z0qz17az5giVRdSlSuQfvEkXFALzTa6tpzkwlDFsjSqiQih9f0M/gw0SWTZdQsH8 cbSOcVtf8sWrX4MfDaKqTIyHQbgsTgTgPWWdLCH1FZTTTkjwnPcWM0FU32lgE0CihTss v5EbhHObzt2Wotd8yEnxaMfAOizBx0G4ZL+I+LUUcA9lQH740Pvz4t5GG0qtkRicKAor sc7p14rhv/eP8vmRxcZAUdo49GqQsQA5f5qgNEM3xLEpQaKCwkXMWGvGixy5dMM3+esJ ldPodvkEZqvIyEnWLytdhqvKdCkRGkm/VsEmDEaZMGlzb728nWL/o8o0w9pLwLn7+2Rl 6vsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=VR9ImPtu; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 61si10271444plr.153.2019.03.18.09.59.55; Mon, 18 Mar 2019 10:00:11 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=VR9ImPtu; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727716AbfCRQ64 (ORCPT + 99 others); Mon, 18 Mar 2019 12:58:56 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:41600 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727089AbfCRQ64 (ORCPT ); Mon, 18 Mar 2019 12:58:56 -0400 Received: by mail-io1-f65.google.com with SMTP id v10so15117363iom.8 for ; Mon, 18 Mar 2019 09:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TCSjK1Dk6w+M0CcBcRsq6gEkd5BO241ZrrOfpC+KdRY=; b=VR9ImPtulW6zwmUf9/D6bnIdxIGodimz2bexHQr69a+ciZHtn5XIi0Xe/ACSGJyobd xOUPiClkN5egBUwB+FYz5nrCRo965NapsF8E8CU91bV2lZJU/8jnVhUAO3k/PLBESQo9 lyl5HV9rUZceWgR1q4UEuHLgDGZbpL27k2DjxC13T4biRnfl9ejxAvSRajYeuWZhGPRP Dj0Dq9hyuYOqjOhHpafPRndtUlQTK102LjEJBmYB7EcvVod3LoUiwwPlKkbNJw//ecP5 i2nGeKG9uTt7CslR6FUDNUWIy4MlkUlBIda/CO2rGtfrcR1sPnssVVHjdNm4P9/N36qv gVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TCSjK1Dk6w+M0CcBcRsq6gEkd5BO241ZrrOfpC+KdRY=; b=DnR93gFR4u6Oy+zxpbmn7YKgx371AqpvT+EEJtCj0EjyXOwCO+PUs+cG37VoTzH2Cv vCJWAMyOZBRSfK8FznQKWCJNc5+J9tjDkgebFwxN+cAPaskyccx74yW9VvI8IyQTjDyT 72yCG2BkUC9OsMyUA4LtPNFwNUEGveHEKGXWYgRGVuogyB8/HbX7TMhG0Tz+zbIIG53r EupldohJ/cB95vZgLVH3Ydr8knFROlD9OTpnhiqJmYHYo7GuAbfTjORFxGWGe3L+05wB jzvgYmJTDPXWjw+lkAi5gbEdPmjWdAUX0Fxro2+ddJEddGf1p4Gkh2X/WtzPx8xd8Fl3 HpGg== X-Gm-Message-State: APjAAAUm4ZGXdSp/E6P0N2761aPzziSyMapsfz8DNoeGo45Rd3Udx6Re 6FVrQKkyP0PnY0Wtn/cYORHMFfJNnXdAyQ1YauvMKrCr X-Received: by 2002:a5d:968a:: with SMTP id m10mr7483612ion.134.1552928334657; Mon, 18 Mar 2019 09:58:54 -0700 (PDT) MIME-Version: 1.0 References: <20190208100554.32196-1-patrick.bellasi@arm.com> <20190208100554.32196-13-patrick.bellasi@arm.com> <20190318165430.n222vuq4tv3ntbod@e110439-lin> In-Reply-To: <20190318165430.n222vuq4tv3ntbod@e110439-lin> From: Suren Baghdasaryan Date: Mon, 18 Mar 2019 09:58:43 -0700 Message-ID: Subject: Re: [PATCH v7 12/15] sched/core: uclamp: Propagate parent clamps To: Patrick Bellasi Cc: LKML , linux-pm@vger.kernel.org, linux-api@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Tejun Heo , "Rafael J . Wysocki" , Vincent Guittot , Viresh Kumar , Paul Turner , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 18, 2019 at 9:54 AM Patrick Bellasi wrote: > > On 14-Mar 09:17, Suren Baghdasaryan wrote: > > On Fri, Feb 8, 2019 at 2:06 AM Patrick Bellasi wrote: > > > > > > In order to properly support hierarchical resources control, the cgroup > > > delegation model requires that attribute writes from a child group never > > > fail but still are (potentially) constrained based on parent's assigned > > > resources. This requires to properly propagate and aggregate parent > > > attributes down to its descendants. > > > > > > Let's implement this mechanism by adding a new "effective" clamp value > > > for each task group. The effective clamp value is defined as the smaller > > > value between the clamp value of a group and the effective clamp value > > > of its parent. This is the actual clamp value enforced on tasks in a > > > task group. > > > > In patch 10 in this series you mentioned "b) do not enforce any > > constraints and/or dependencies between the parent and its child > > nodes" > > > > This patch seems to change that behavior. If so, should it be documented? > > Not, I actually have to update the changelog of that patch. > > What I mean is that we do not enforce constraints among "requested" > values thus ensuring that each sub-group can always request a clamp > value. > Of course, if it gets that value or not depends on parent constraints, > which are propagated down the hierarchy under the form of "effective" > values by cpu_util_update_heir() > > I'll fix the changelog in patch 10 which seems to be confusing for > Tejun too. > > [...] > > > > @@ -7011,6 +7029,53 @@ static void cpu_cgroup_attach(struct cgroup_taskset *tset) > > > } > > > > > > #ifdef CONFIG_UCLAMP_TASK_GROUP > > > +static void cpu_util_update_hier(struct cgroup_subsys_state *css, > > > > s/cpu_util_update_hier/cpu_util_update_heir ? > > Mmm... why? > > That "_hier" stands for "hierarchical". Yeah, I realized that later on but did not want to create more chatter. _hier seems fine. > However, since there we update the effective values, maybe I can > better rename it in "_eff" ? > > > > + unsigned int clamp_id, unsigned int bucket_id, > > > + unsigned int value) > > > +{ > > > + struct cgroup_subsys_state *top_css = css; > > > + struct uclamp_se *uc_se, *uc_parent; > > > + > > > + css_for_each_descendant_pre(css, top_css) { > > > + /* > > > + * The first visited task group is top_css, which clamp value > > > + * is the one passed as parameter. For descendent task > > > + * groups we consider their current value. > > > + */ > > > + uc_se = &css_tg(css)->uclamp[clamp_id]; > > > + if (css != top_css) { > > > + value = uc_se->value; > > > + bucket_id = uc_se->effective.bucket_id; > > > + } > > > + uc_parent = NULL; > > > + if (css_tg(css)->parent) > > > + uc_parent = &css_tg(css)->parent->uclamp[clamp_id]; > > > + > > > + /* > > > + * Skip the whole subtrees if the current effective clamp is > > > + * already matching the TG's clamp value. > > > + * In this case, all the subtrees already have top_value, or a > > > + * more restrictive value, as effective clamp. > > > + */ > > > + if (uc_se->effective.value == value && > > > + uc_parent && uc_parent->effective.value >= value) { > > > + css = css_rightmost_descendant(css); > > > + continue; > > > + } > > > + > > > + /* Propagate the most restrictive effective value */ > > > + if (uc_parent && uc_parent->effective.value < value) { > > > + value = uc_parent->effective.value; > > > + bucket_id = uc_parent->effective.bucket_id; > > > + } > > > + if (uc_se->effective.value == value) > > > + continue; > > > + > > > + uc_se->effective.value = value; > > > + uc_se->effective.bucket_id = bucket_id; > > > + } > > > +} > > > + > > > static int cpu_util_min_write_u64(struct cgroup_subsys_state *css, > > > struct cftype *cftype, u64 min_value) > > > { > > [...] > > Cheers, > Patrick > > -- > #include > > Patrick Bellasi