lkml.org 
[lkml]   [2019]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v6 10/16] sched/core: Add uclamp_util_with()
On 23-Jan 14:33, Peter Zijlstra wrote:
> On Tue, Jan 15, 2019 at 10:15:07AM +0000, Patrick Bellasi wrote:
> > +static __always_inline
> > +unsigned int uclamp_util_with(struct rq *rq, unsigned int util,
> > + struct task_struct *p)
> > {
> > unsigned int min_util = READ_ONCE(rq->uclamp[UCLAMP_MIN].value);
> > unsigned int max_util = READ_ONCE(rq->uclamp[UCLAMP_MAX].value);
> >
> > + if (p) {
> > + min_util = max(min_util, uclamp_effective_value(p, UCLAMP_MIN));
> > + max_util = max(max_util, uclamp_effective_value(p, UCLAMP_MAX));
> > + }
> > +
>
> Like I think you mentioned earlier; this doesn't look right at all.

What we wanna do here is to compute what _will_ be the clamp values of
a CPU if we enqueue *p on it.

The code above starts from the current CPU clamp value and mimics what
uclamp will do in case we move the task there... which is always a max
aggregation.

> Should that not be something like:
>
> lo = READ_ONCE(rq->uclamp[UCLAMP_MIN].value);
> hi = READ_ONCE(rq->uclamp[UCLAMP_MAX].value);
>
> min_util = clamp(uclamp_effective(p, UCLAMP_MIN), lo, hi);
> max_util = clamp(uclamp_effective(p, UCLAMP_MAX), lo, hi);

Here you end up with a restriction of the task clamp (effective)
clamps values considering the CPU clamps... which is different.

Why do you think we should do that?... perhaps I'm missing something.

--
#include <best/regards.h>

Patrick Bellasi

\
 
 \ /
  Last update: 2019-01-23 15:51    [W:0.435 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site