[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150729130147.GB11554@lerouge>
Date: Wed, 29 Jul 2015 15:01:48 +0200
From: Frederic Weisbecker <fweisbec@...il.com>
To: Chris Metcalf <cmetcalf@...hip.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Preeti U Murthy <preeti@...ux.vnet.ibm.com>,
Christoph Lameter <cl@...ux.com>,
Ingo Molnar <mingo@...nel.org>,
Viresh Kumar <viresh.kumar@...aro.org>,
Rik van Riel <riel@...hat.com>
Subject: Re: [PATCH 07/10] sched: Migrate sched to use new tick dependency
mask model
On Fri, Jul 24, 2015 at 12:56:42PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+static inline void sched_update_tick_dependency(struct rq *rq)
> >+{
> >+ int cpu;
> >+
> >+ if (!tick_nohz_full_enabled())
> >+ return;
> >+
> >+ cpu = cpu_of(rq);
> >+
> >+ if (!tick_nohz_full_cpu(rq->cpu))
> >+ return;
> >+
> >+ if (sched_can_stop_tick(rq))
> >+ tick_nohz_clear_tick_dependency_cpu(TICK_SCHED_BIT, cpu);
> >+ else
> >+ tick_nohz_set_tick_dependency_cpu(TICK_SCHED_BIT, cpu);
> >+}
>
> Is it worth asserting that the rq is locked at this point? Presumably that's
> a requirement so that the cpu can't change out from under you.
Indeed it has become a requirement here. I'll add a check.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists