linux-kernel - Re: [PATCH 10/10] sched,fair: flatten hierarchical runqueues

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 linux-hardening linux-cve-announce 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]

Message-ID: <5c59793c664eebfa872f9d5a99346fc6e1c68c7f.camel@surriel.com>
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)