lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 01 Jul 2019 16:58:41 -0400
From:   Rik van Riel <riel@...riel.com>
To:     Josef Bacik <josef@...icpanda.com>
Cc:     linux-kernel@...r.kernel.org, kernel-team@...com, pjt@...gle.com,
        dietmar.eggemann@....com, peterz@...radead.org, mingo@...hat.com,
        morten.rasmussen@....com, tglx@...utronix.de,
        mgorman@...hsingularity.net, vincent.guittot@...aro.org
Subject: Re: [PATCH 10/10] sched,fair: flatten hierarchical runqueues

On Mon, 2019-07-01 at 16:34 -0400, Josef Bacik wrote:
> On Fri, Jun 28, 2019 at 04:49:13PM -0400, Rik van Riel wrote:
> > @@ -2703,16 +2716,28 @@ static inline void
> > update_scan_period(struct task_struct *p, int new_cpu)
> >  static void
> >  account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity
> > *se)
> >  {
> > -	update_load_add(&cfs_rq->load, se->load.weight);
> > -	if (!parent_entity(se))
> > +	struct rq *rq;
> > +
> > +	if (task_se_in_cgroup(se)) {
> > +		struct cfs_rq *cgroup_rq = group_cfs_rq_of_parent(se);
> > +		unsigned long h_weight;
> > +
> > +		update_load_add(&cgroup_rq->load, se->load.weight);
> > +		cgroup_rq->nr_running++;
> > +
> > +		/* Add the hierarchical weight to the CPU rq */
> > +		h_weight = task_se_h_weight(se);
> > +		se->enqueued_h_weight = h_weight;
> > +		update_load_add(&rq_of(cfs_rq)->load, h_weight);
> 
> Ok I think this is where we need to handle the newly enqueued se's
> potential
> weight.  Right now task_se_h_weight() is based on it's weight _and_
> its load.
> So it's really it's task_se_h_weighted_load_avg, and not really
> task_se_h_weight, right?  Instead we should separate these two things
> out, one
> gives us our heirarchal load, and one that gives us our heirarchal
> weight based
> purely on the ratio of (our weight) / (total se weight on
> parent).  Then we can
> take this number and max it with the heirarchal load avg and use that
> with the
> update_load_add.  Does that make sense?  Thanks,

Yes, I think that makes sense.

The hierarchical group weights can be computed periodically,
in the same way the hierarchical group load averages are.

We may still end up with stale values occasionally, if the
values were already computed the same jiffy, or when the
values of another group (with a shared parent) have not been
propagated up yet, but things should converge relatively
quickly.

It means update_cfs_rq_h_load() and update_blocked_averages()
will propagate both load averages and instantaneous weights,
which should be easy enough to add.

I'll give it a try!

-- 
All Rights Reversed.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists