[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180220160101.GB4589@e105550-lin.cambridge.arm.com>
Date: Tue, 20 Feb 2018 16:01:01 +0000
From: Morten Rasmussen <morten.rasmussen@....com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...hat.com, valentin.schneider@....com,
dietmar.eggemann@....com, vincent.guittot@...aro.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] sched/fair: Add group_misfit_task load-balance type
On Mon, Feb 19, 2018 at 02:58:42PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 19, 2018 at 02:56:44PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 15, 2018 at 04:20:49PM +0000, Morten Rasmussen wrote:
> > > @@ -6733,9 +6758,12 @@ done: __maybe_unused
> > > if (hrtick_enabled(rq))
> > > hrtick_start_fair(rq, p);
> > >
> > > + update_misfit_status(p, rq);
> > > +
> > > return p;
> > >
> > > idle:
> > > + update_misfit_status(NULL, rq);
> > > new_tasks = idle_balance(rq, rf);
> > >
> > > /*
> >
> > So we set a point when picking a task (or tick). We clear said pointer
> > when idle.
>
> N/m, I can't read today. You only store the load, not the actual task.
It is a very valid question though.
Storing the load of the misfit task isn't the perfect solution as there
is no guarantee that we actually end up pulling the misfit task if some
other task happens to be on the rq when we balance. However, as I think
you are hinting, we will get into all sorts of interesting races if we
store a pointer to the actual task.
In most real scenarios it appears to be 'good enough'. The typical
misfit scenario is one always-running task and potentially a few small
tasks showing up periodically. In that case we are most likely to see
the always-running task when we are balancing.
Powered by blists - more mailing lists