* [PATCH] 2.5: don't miss a preemption
@ 2002-04-15 19:58 Robert Love
2002-04-15 20:50 ` Hugh Dickins
0 siblings, 1 reply; 3+ messages in thread
From: Robert Love @ 2002-04-15 19:58 UTC (permalink / raw)
To: linux-kernel
Current kernel preemption code opens a small window between the check
for need_resched in schedule and the setting of preempt_count to zero in
preempt_schedule. While this window is generally short (a few cycles)
the resulting period of non-preemptibility could be as long as the next
timer tick - much longer, in fact, if a lock is obtained in the interim.
This patch checks for need_resched in preempt_schedule after setting
preempt_count back to zero, before returning. The overhead is
negligible and it is crucial to never miss a preemption opportunity.
Also fixes/clarifies some comments. Patch is against 2.5.8 ... enjoy,
Robert Love
diff -urN linux-2.5.8/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.8/kernel/sched.c Sun Apr 14 15:18:47 2002
+++ linux/kernel/sched.c Mon Apr 15 15:49:44 2002
@@ -765,8 +765,8 @@
spin_lock_irq(&rq->lock);
/*
- * if entering from preempt_schedule, off a kernel preemption,
- * go straight to picking the next task.
+ * if entering off of a kernel preemption go
+ * straight to picking the next task.
*/
if (unlikely(preempt_get_count() & PREEMPT_ACTIVE))
goto pick_next_task;
@@ -842,7 +842,9 @@
#ifdef CONFIG_PREEMPT
/*
- * this is is the entry point to schedule() from in-kernel preemption.
+ * this is is the entry point to schedule() from in-kernel preemption
+ * off of preempt_enable. Preemptions off return-from-interrupt are
+ * handled directly in that codepath.
*/
asmlinkage void preempt_schedule(void)
{
@@ -851,10 +853,15 @@
if (unlikely(ti->preempt_count))
return;
+need_resched:
ti->preempt_count = PREEMPT_ACTIVE;
schedule();
ti->preempt_count = 0;
barrier();
+
+ /* we could miss a preemption between schedule() and now */
+ if (unlikely(test_thread_flag(TIF_NEED_RESCHED)))
+ goto need_resched;
}
#endif /* CONFIG_PREEMPT */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] 2.5: don't miss a preemption
2002-04-15 19:58 [PATCH] 2.5: don't miss a preemption Robert Love
@ 2002-04-15 20:50 ` Hugh Dickins
2002-04-15 21:25 ` Robert Love
0 siblings, 1 reply; 3+ messages in thread
From: Hugh Dickins @ 2002-04-15 20:50 UTC (permalink / raw)
To: Robert Love; +Cc: linux-kernel
On 15 Apr 2002, Robert Love wrote:
>
> This patch checks for need_resched in preempt_schedule after setting
> preempt_count back to zero, before returning. The overhead is
> negligible and it is crucial to never miss a preemption opportunity.
I'm curious: why is it crucial to never miss a preemption opportunity?
Hugh
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] 2.5: don't miss a preemption
2002-04-15 20:50 ` Hugh Dickins
@ 2002-04-15 21:25 ` Robert Love
0 siblings, 0 replies; 3+ messages in thread
From: Robert Love @ 2002-04-15 21:25 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linux-kernel
On Mon, 2002-04-15 at 16:50, Hugh Dickins wrote:
> On 15 Apr 2002, Robert Love wrote:
> >
> > This patch checks for need_resched in preempt_schedule after setting
> > preempt_count back to zero, before returning. The overhead is
> > negligible and it is crucial to never miss a preemption opportunity.
>
> I'm curious: why is it crucial to never miss a preemption opportunity?
Two main reasons:
(1) In 2.5, we have a kernel preemption model that makes the
fully preemptible, subject to SMP locking constraints and
a few other rules. Without this patch, we break this model
and do not allow preemption when it is in fact legal.
(2) Like I said, it may be awhile before we can preempt again.
If we take a lock after return from schedule but before the
next interrupt, it can be many tens (or hundreds) of milliseconds
before we release the lock and subsequently preempt. If
need_resched was set in response to an important real-time
application, the wait can be detrimental. Servicing apps
as soon as they become runnable is the point of preempt-kernel,
anyhow.
It is not crucial in the sense we break anything; merely that we are
working toward providing very efficient response and dispatch to
interactive and real-time applications and we _must_ respond to them as
soon as possible.
Robert Love
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2002-04-15 21:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-15 19:58 [PATCH] 2.5: don't miss a preemption Robert Love
2002-04-15 20:50 ` Hugh Dickins
2002-04-15 21:25 ` Robert Love
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).