All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Bellasi <patrick.bellasi@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>, Tejun Heo <tj@kernel.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Paul Turner <pjt@google.com>,
	Quentin Perret <quentin.perret@arm.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Morten Rasmussen <morten.rasmussen@arm.com>,
	Juri Lelli <juri.lelli@redhat.com>, Todd Kjos <tkjos@google.com>,
	Joel Fernandes <joelaf@google.com>,
	Steve Muckle <smuckle@google.com>,
	Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v5 07/15] sched/core: uclamp: add clamp group bucketing support
Date: Tue, 13 Nov 2018 07:29:48 -0800	[thread overview]
Message-ID: <20181113152948.GC7681@darkstar> (raw)
In-Reply-To: <20181112000910.GC3038@worktop>

On 12-Nov 01:09, Peter Zijlstra wrote:
> On Mon, Oct 29, 2018 at 06:33:02PM +0000, Patrick Bellasi wrote:
> > The number of clamp groups configured at compile time defines the range
> > of utilization clamp values tracked by each CPU clamp group.
> > For example, with the default configuration:
> >    CONFIG_UCLAMP_GROUPS_COUNT 5
> > we will have 5 clamp groups tracking 20% utilization each. In this case,
> > a task with util_min=25% will have group_id=1.
> 
> OK I suppose; but should we not do a wholesale s/group/bucket/ at this
> point?

Yes, if bucketization is acceptable, we should probably rename.

Question is: are you ok for a renaming in this patch. or you better
prefer I use that naming since the beginning ?

If we wanna use "bucket" since the beginning, then we should also
probably squash the entire patch into the previous ones and drop this
one.

I personally prefer to keep this concept into a separate patch, but at
the same time I don't very like the idea of a massive renaming in this
patch.

> 
> We should probably raise the minimum number of buckets from 1 though :-)

Mmm... the default is already set to what fits into a single cache
line... perhaps we can use that as a minimum too ?

But. technically we can (partially) track different clamp values also
with just one bucket... (explanation in the following comment).

> > +/*
> > + * uclamp_group_value: get the "group value" for a given "clamp value"
> > + * @value: the utiliation "clamp value" to translate
> > + *
> > + * The number of clamp group, which is defined at compile time, allows to
> > + * track a finite number of different clamp values. Thus clamp values are
> > + * grouped into bins each one representing a different "group value".
> > + * This method returns the "group value" corresponding to the specified
> > + * "clamp value".
> > + */
> > +static inline unsigned int uclamp_group_value(unsigned int clamp_value)
> > +{
> > +#define UCLAMP_GROUP_DELTA (SCHED_CAPACITY_SCALE / CONFIG_UCLAMP_GROUPS_COUNT)
> > +#define UCLAMP_GROUP_UPPER (UCLAMP_GROUP_DELTA * CONFIG_UCLAMP_GROUPS_COUNT)
> > +
> > +	if (clamp_value >= UCLAMP_GROUP_UPPER)
> > +		return SCHED_CAPACITY_SCALE;
> > +
> > +	return UCLAMP_GROUP_DELTA * (clamp_value / UCLAMP_GROUP_DELTA);
> > +}
> 
> Can't we further simplify; I mean, at this point all we really need to
> know is the rq's highest group_id that is in use. We don't need to
> actually track the value anymore.

This will force to track each clamp value with the exact bucket value.

Instead, by tracking the actual clamp value within a bucket, we have
the chance to updte the bucket value to the actual (max) clamp value
of the RUNNABLE tasks in that bucket.

In a properly configured system, this allows to track exact clamp
values with a minimum number of buckets.

-- 
#include <best/regards.h>

Patrick Bellasi

  reply	other threads:[~2018-11-13 15:29 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-29 18:32 [PATCH v5 00/15] Add utilization clamping support Patrick Bellasi
2018-10-29 18:32 ` Patrick Bellasi
2018-10-29 18:32 ` [PATCH v5 01/15] sched/core: uclamp: extend sched_setattr to support utilization clamping Patrick Bellasi
2018-10-29 19:33   ` Randy Dunlap
2018-11-07 12:09   ` Peter Zijlstra
2018-10-29 18:32 ` [PATCH v5 02/15] sched/core: make sched_setattr able to tune the current policy Patrick Bellasi
2018-11-07 12:11   ` Peter Zijlstra
2018-11-07 13:50     ` Patrick Bellasi
2018-11-07 13:58       ` Peter Zijlstra
2018-10-29 18:32 ` [PATCH v5 03/15] sched/core: uclamp: map TASK's clamp values into CPU's clamp groups Patrick Bellasi
2018-11-07 12:19   ` Peter Zijlstra
2018-11-07 14:19     ` Patrick Bellasi
2018-11-07 14:42       ` Peter Zijlstra
2018-11-07 14:56         ` Patrick Bellasi
2018-11-07 13:16   ` Peter Zijlstra
2018-11-07 13:57     ` Patrick Bellasi
2018-11-07 14:14       ` Peter Zijlstra
2018-11-07 13:35   ` Peter Zijlstra
2018-11-07 14:48     ` Patrick Bellasi
2018-11-07 14:55       ` Peter Zijlstra
2018-11-07 15:04         ` Patrick Bellasi
2018-11-07 13:44   ` Peter Zijlstra
2018-11-07 14:24     ` Patrick Bellasi
2018-11-07 14:44       ` Peter Zijlstra
2018-11-07 14:58         ` Patrick Bellasi
2018-11-07 14:37   ` Peter Zijlstra
2018-11-07 14:53     ` Patrick Bellasi
2018-10-29 18:32 ` [PATCH v5 04/15] sched/core: uclamp: add CPU's clamp groups accounting Patrick Bellasi
2018-10-29 18:42   ` Patrick Bellasi
2018-10-29 18:32 ` [PATCH v5 04/15] sched/core: uclamp: add CPU's clamp groups refcounting Patrick Bellasi
2018-11-11 16:47   ` Peter Zijlstra
2018-11-13 15:11     ` Patrick Bellasi
2018-11-22 14:20       ` Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 05/15] sched/core: uclamp: update CPU's refcount on clamp changes Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 06/15] sched/core: uclamp: enforce last task UCLAMP_MAX Patrick Bellasi
2018-11-11 17:08   ` Peter Zijlstra
2018-11-13 15:14     ` Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 07/15] sched/core: uclamp: add clamp group bucketing support Patrick Bellasi
2018-11-12  0:09   ` Peter Zijlstra
2018-11-13 15:29     ` Patrick Bellasi [this message]
2018-10-29 18:33 ` [PATCH v5 08/15] sched/core: uclamp: add system default clamps Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 09/15] sched/cpufreq: uclamp: add utilization clamping for FAIR tasks Patrick Bellasi
2018-11-07 11:38   ` Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 10/15] sched/cpufreq: uclamp: add utilization clamping for RT tasks Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 11/15] sched/core: uclamp: extend CPU's cgroup controller Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 12/15] sched/core: uclamp: propagate parent clamps Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 13/15] sched/core: uclamp: map TG's clamp values into CPU's clamp groups Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 14/15] sched/core: uclamp: use TG's clamps to restrict Task's clamps Patrick Bellasi
2018-10-29 18:47   ` Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 14/15] sched/core: uclamp: use TG's clamps to restrict TASK's clamps Patrick Bellasi
2018-10-29 18:33 ` [PATCH v5 15/15] sched/core: uclamp: update CPU's refcount on TG's clamp changes Patrick Bellasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181113152948.GC7681@darkstar \
    --to=patrick.bellasi@arm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=joelaf@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=morten.rasmussen@arm.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=quentin.perret@arm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=smuckle@google.com \
    --cc=surenb@google.com \
    --cc=tj@kernel.org \
    --cc=tkjos@google.com \
    --cc=vincent.guittot@linaro.org \
    --cc=viresh.kumar@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.