[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150929110049.7b9de3eb@gandalf.local.home>
Date: Tue, 29 Sep 2015 11:00:49 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
fweisbec@...il.com, oleg@...hat.com, umgwanakikbuti@...il.com,
tglx@...utronix.de
Subject: Re: [RFC][PATCH 01/11] sched: Simplify INIT_PREEMPT_COUNT
[ Resend, with the Cc list back ]
On Tue, 29 Sep 2015 16:35:59 +0200
Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Sep 29, 2015 at 10:37:29AM -0400, Steven Rostedt wrote:
> > On Tue, 29 Sep 2015 11:28:26 +0200
> > Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > > As per commit d86ee4809d03 ("sched: optimize cond_resched()") we need
> > > PREEMPT_ACTIVE to avoid cond_resched() from working before the
> > > scheduler is setup.
> > >
> > > However, keeping preemption disabled should do the same thing already,
> > > making the PREEMPT_ACTIVE part entirely redundant.
> >
> > Thus PREEMPT_ACTIVE wasn't needed at that commit either, or was it?
>
> Correct. We might have actually discussed that at that time but decided
> to be conservative -- but these be vague memories..
Hmm, I just looked closer and I'm wondering if this still works?
We have:
#ifdef CONFIG_PREEMPT_COUNT
#define PREEMPT_DISABLED (1 + PREEMPT_ENABLED)
#else
#define PREEMPT_DISABLED PREEMPT_ENABLED
#endif
Now if we just remove the PREEMPT_ACTIVE from the INIT_PREEMPT_COUNT,
when CONFIG_PREEMPT_COUNT is not set, wouldn't a _cond_resched() in
boot up schedule?
-- Steve
--
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