* [Fwd: lost need_resched flag re-introduced?]
@ 2000-12-07 1:13 Jun Sun
2000-12-07 17:21 ` kuznet
0 siblings, 1 reply; 4+ messages in thread
From: Jun Sun @ 2000-12-07 1:13 UTC (permalink / raw)
To: linux-kernel
I did not get reply from Linus. Now try my luck with the kernel mailing
list. Please cc your reply to my email account. I stopped watching the
mailing list anymore.
Thanks.
Jun
Jun Sun wrote:
>
> Linus,
>
> A while back I reported the lost need_resched flag bug ( it happens if
> need_resched is set right before switch_to() is called). Later on a one-line
> fix is added to __schedule_tail().
>
> current->need_resched |= prev->need_resched;
>
> I looked at the latest kernel and found this one is gone. Is the lost
> need_resched problem taken care of in some other way? Or is it re-introduced?
>
> In any case, I was going to propose a minor fix over the original one-line
> fix. See the patch below.
>
> On RISC machines, the original fix leaves a small window for setting the wrong
> flag. A pseudo assembly code for the original fix is shown as follows:
>
> 1. load current->need_resched to R1
> 2. load prev->need_resched to R2
> 3. R1 = R1 | R2
> 4. store R1 to current->need_resched
>
> If at 1) both need_resched flags are 0, and an interrupt happens between 1)
> and 4), which sets current->resched to 1, we will have wrong result for
> current->need_resched after step 4).
>
> Jun
>
> inux/kernel/sched.c: 1.1 1.2 jsun 00/10/31 10:22:44 (modified, needs delta)
>
> @@ -455,7 +455,9 @@
> */
> static inline void __schedule_tail(struct task_struct *prev)
> {
> - current->need_resched |= prev->need_resched;
> + if (prev->need_resched) {
> + current->need_resched = 1;
> + }
> #ifdef CONFIG_SMP
> if ((prev->state == TASK_RUNNING) &&
> (prev != idle_task(smp_processor_id()))) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Fwd: lost need_resched flag re-introduced?]
2000-12-07 1:13 [Fwd: lost need_resched flag re-introduced?] Jun Sun
@ 2000-12-07 17:21 ` kuznet
2000-12-07 18:51 ` Jun Sun
0 siblings, 1 reply; 4+ messages in thread
From: kuznet @ 2000-12-07 17:21 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-kernel
Hello!
> > A while back I reported the lost need_resched flag bug ( it happens if
> > need_resched is set right before switch_to() is called). Later on a one-line
> > fix is added to __schedule_tail().
> >
> > current->need_resched |= prev->need_resched;
> >
> > I looked at the latest kernel and found this one is gone. Is the lost
> > need_resched problem taken care of in some other way? Or is it re-introduced?
It is removed not only because it was wrong (which you have found too),
but because it was useless even if copied correctly.
current->need_resched is not changed in interrupt context outside
runqueue lock except for scheduler timer, where copying results
in nothing but spurious reschedule.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Fwd: lost need_resched flag re-introduced?]
2000-12-07 17:21 ` kuznet
@ 2000-12-07 18:51 ` Jun Sun
2000-12-07 18:56 ` kuznet
0 siblings, 1 reply; 4+ messages in thread
From: Jun Sun @ 2000-12-07 18:51 UTC (permalink / raw)
To: kuznet; +Cc: linux-kernel
kuznet@ms2.inr.ac.ru wrote:
>
> Hello!
>
> > > A while back I reported the lost need_resched flag bug ( it happens if
> > > need_resched is set right before switch_to() is called). Later on a one-line
> > > fix is added to __schedule_tail().
> > >
> > > current->need_resched |= prev->need_resched;
> > >
> > > I looked at the latest kernel and found this one is gone. Is the lost
> > > need_resched problem taken care of in some other way? Or is it re-introduced?
>
> It is removed not only because it was wrong (which you have found too),
> but because it was useless even if copied correctly.
>
> current->need_resched is not changed in interrupt context outside
> runqueue lock except for scheduler timer, where copying results
> in nothing but spurious reschedule.
>
> Alexey
Alexey,
I think wake_up_process() is called in interrupt routine quite often and it
will set need_resched flag (through reschedule_idle()). ???
I did several run time tests and confirmed the missing need_resched flag was
happening. Ether some new code takes care of it. Or it is still there.
Jun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Fwd: lost need_resched flag re-introduced?]
2000-12-07 18:51 ` Jun Sun
@ 2000-12-07 18:56 ` kuznet
0 siblings, 0 replies; 4+ messages in thread
From: kuznet @ 2000-12-07 18:56 UTC (permalink / raw)
To: Jun Sun; +Cc: linux-kernel
Hello!
> I think wake_up_process() is called in interrupt routine quite often and it
> will set need_resched flag (through reschedule_idle()). ???
It sets _right_ flag cpu_curr(this_cpu)->need_resched, rather than
current->need_resched.
> happening. Ether some new code takes care of it. Or it is still there.
? 8)
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2000-12-07 19:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-12-07 1:13 [Fwd: lost need_resched flag re-introduced?] Jun Sun
2000-12-07 17:21 ` kuznet
2000-12-07 18:51 ` Jun Sun
2000-12-07 18:56 ` kuznet
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox