From: Ingo Molnar <mingo@elte.hu>
To: Andrew Morton <akpm@osdl.org>
Cc: Thomas Hood <jdthood@yahoo.co.uk>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Documentation/preempt-locking.txt clarification
Date: Wed, 10 Nov 2004 11:59:51 +0100 [thread overview]
Message-ID: <20041110105951.GA3714@elte.hu> (raw)
In-Reply-To: <20041110014543.143b8ff3.akpm@osdl.org>
* Andrew Morton <akpm@osdl.org> wrote:
> I think the statement is in fact false. Ingo, what's your take on
> this paragraph, from preempt-locking.txt?
>
> An additional concern is proper usage of local_irq_disable and
> local_irq_save. These may be used to protect from preemption,
> however, on exit, if preemption may be enabled, a test to see if
> preemption is required should be done. If these are called from the
> spin_lock and read/write lock macros, the right thing is done. They
> may also be called within a spin-lock protected region, however, if
> they are ever called outside of this context, a test for preemption
> should be made. Do note that calls from interrupt context or bottom
> half/ tasklets are also protected by preemption locks and so may use
> the versions which do not check preemption.
seems mostly correct. The issue is that if a wakeup is done from within
an irqs-off critical section (perfectly possible - a simple printk can
trigger a wakeup) then the current task may be marked for rescheduling
but cannot do it just yet. So when interrupts are re-enabled again
(outside of a critical section) a manual preempt_check_resched() is
necessary in the generic case, or else we miss the reschedule.
In special cases, if no wakeup may happen from within the irqs-off
section then the manual preemption can be skipped, because asynchronous
reschedules (e.g. on SMP) always come in the form of interrupts. I'd
wager that in fact these 'special cases' are in the majority, but
there's no guarantee.
Ingo
next prev parent reply other threads:[~2004-11-10 9:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1073302283.1903.85.camel@thanatos.hubertnet>
[not found] ` <1074561880.26456.26.camel@localhost>
2004-11-10 8:21 ` Thomas Hood
2004-11-10 8:57 ` Andrew Morton
2004-11-10 9:27 ` Thomas Hood
2004-11-10 9:45 ` Andrew Morton
2004-11-10 10:59 ` Ingo Molnar [this message]
2004-11-10 11:03 ` Ingo Molnar
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=20041110105951.GA3714@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=jdthood@yahoo.co.uk \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome