[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181022165631.GE3117@worktop.programming.kicks-ass.net>
Date: Mon, 22 Oct 2018 18:56:31 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Steve Sistare <steven.sistare@...cle.com>
Cc: mingo@...hat.com, subhra.mazumdar@...cle.com,
dhaval.giani@...cle.com, rohit.k.jain@...cle.com,
daniel.m.jordan@...cle.com, pavel.tatashin@...rosoft.com,
matt@...eblueprint.co.uk, umgwanakikbuti@...il.com,
riel@...hat.com, jbacik@...com, juri.lelli@...hat.com,
linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH 04/10] sched/fair: Dynamically update cfs_overload_cpus
On Mon, Oct 22, 2018 at 07:59:35AM -0700, Steve Sistare wrote:
> An overloaded CPU has more than 1 runnable task. When a CFS task wakes
> on a CPU, if h_nr_running transitions from 1 to more, then set the CPU in
> the cfs_overload_cpus bitmap. When a CFS task sleeps, if h_nr_running
> transitions from 2 to less, then clear the CPU in cfs_overload_cpus.
> @@ -5111,8 +5147,12 @@ static inline void hrtick_update(struct rq *rq)
> update_cfs_group(se);
> }
>
> - if (!se)
> + if (!se) {
> add_nr_running(rq, 1);
> + if (prev_nr == 1)
> + overload_set(rq);
> +
> + }
This is very similar to what RT already has, except they also track if
the tasks in question is in fact migratable (p->nr_cpus_allowed > 1).
And similarly, it might make sense to use the sparse mask thing over
there.
Powered by blists - more mailing lists