From: Peter Zijlstra <peterz@infradead.org>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC PATCH 4/4] sched: Account PREEMPT_ACTIVE context as atomic
Date: Wed, 28 Jan 2015 16:46:37 +0100 [thread overview]
Message-ID: <20150128154637.GI23038@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <1422404652-29067-5-git-send-email-fweisbec@gmail.com>
On Wed, Jan 28, 2015 at 01:24:12AM +0100, Frederic Weisbecker wrote:
> PREEMPT_ACTIVE implies non-preemptible context and thus atomic context
> despite what in_atomic*() APIs reports about it. These functions
> shouldn't ignore this value like they are currently doing.
>
> It appears that these APIs were ignoring PREEMPT_ACTIVE in order to
> ease the check in schedule_debug(). Meanwhile it is sufficient to rely
> on PREEMPT_ACTIVE in order to disable preemption in __schedule().
>
> So lets fix the in_atomic*() APIs and simplify the preempt count ops
> on __schedule() callers.
So what I think the history is here is that PREEMPT_ACTIVE is/was seen
as a flag, protecting recursion, not so much a preempt-disable.
By doing this, you loose that separation.
Note that (at least on x86) we have another flag in the preempt count.
And I don't think the generated code really changes, the only difference
is the value added/subtracted and that's an encoded immediate I think.
next prev parent reply other threads:[~2015-01-28 20:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 0:24 [PATCH 0/4] sched: schedule/preempt optimizations and cleanups Frederic Weisbecker
2015-01-28 0:24 ` [PATCH 1/4] sched: Pull resched loop to __schedule() callers Frederic Weisbecker
2015-02-04 14:36 ` [tip:sched/core] " tip-bot for Frederic Weisbecker
2015-01-28 0:24 ` [RFC PATCH 2/4] sched: Use traced preempt count operations to toggle PREEMPT_ACTIVE Frederic Weisbecker
2015-01-28 1:42 ` Steven Rostedt
2015-01-28 13:59 ` Frederic Weisbecker
2015-01-28 15:04 ` Steven Rostedt
2015-01-28 15:42 ` Peter Zijlstra
2015-02-02 17:22 ` Frederic Weisbecker
2015-01-28 0:24 ` [PATCH 3/4] sched: Pull preemption disablement to __schedule() caller Frederic Weisbecker
2015-01-28 15:50 ` Peter Zijlstra
2015-02-02 17:53 ` Frederic Weisbecker
2015-02-03 10:53 ` Peter Zijlstra
2015-02-04 17:31 ` Frederic Weisbecker
2015-02-04 17:48 ` Peter Zijlstra
2015-01-28 0:24 ` [RFC PATCH 4/4] sched: Account PREEMPT_ACTIVE context as atomic Frederic Weisbecker
2015-01-28 15:46 ` Peter Zijlstra [this message]
2015-02-02 17:29 ` Frederic Weisbecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150128154637.GI23038@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=rostedt@goodmis.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.