* [Adeos-main] x86-32: Unpreemptible return from __ipipe_handle_irq
@ 2010-09-08 16:53 Jan Kiszka
2010-09-13 7:51 ` Philippe Gerum
0 siblings, 1 reply; 2+ messages in thread
From: Jan Kiszka @ 2010-09-08 16:53 UTC (permalink / raw)
To: Philippe Gerum; +Cc: adeos-main
Hi Philippe,
__ipipe_handle_irq:
#if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
/*
* Prevent a spurious rescheduling from being triggered on
* preemptible kernels along the way out through
* ret_from_intr.
*/
if ((long)regs->orig_ax < 0)
__set_bit(IPIPE_STALL_FLAG, &ipipe_root_cpudom_var(status));
#endif /* CONFIG_SMP */
But this defeats any preemption of kernel contexts on CONFIG_PREEMPT,
doesn't it? __ipipe_test_preemption should now always fail.
What kind of spurious rescheduling has to be prevented?
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Adeos-main] x86-32: Unpreemptible return from __ipipe_handle_irq
2010-09-08 16:53 [Adeos-main] x86-32: Unpreemptible return from __ipipe_handle_irq Jan Kiszka
@ 2010-09-13 7:51 ` Philippe Gerum
0 siblings, 0 replies; 2+ messages in thread
From: Philippe Gerum @ 2010-09-13 7:51 UTC (permalink / raw)
To: Jan Kiszka; +Cc: adeos-main
On Wed, 2010-09-08 at 18:53 +0200, Jan Kiszka wrote:
> Hi Philippe,
>
> __ipipe_handle_irq:
>
> #if defined(CONFIG_X86_32) && defined(CONFIG_SMP)
> /*
> * Prevent a spurious rescheduling from being triggered on
> * preemptible kernels along the way out through
> * ret_from_intr.
> */
> if ((long)regs->orig_ax < 0)
> __set_bit(IPIPE_STALL_FLAG, &ipipe_root_cpudom_var(status));
> #endif /* CONFIG_SMP */
>
> But this defeats any preemption of kernel contexts on CONFIG_PREEMPT,
> doesn't it? __ipipe_test_preemption should now always fail.
>
> What kind of spurious rescheduling has to be prevented?
This hack was introduced in 2.6.9; disabling preemption on the IRQ
return path was working around a SMP issue causing a crash. I would not
be surprised if such code was only papering over a migration issue in
fact, which probably disappeared later in the pipeline implementation.
x86_64 never required this, and it is likely time to re-assess the need
for this hack, and fix the issue properly if ever it still makes sense.
>
> Jan
>
--
Philippe.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-09-13 7:51 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-08 16:53 [Adeos-main] x86-32: Unpreemptible return from __ipipe_handle_irq Jan Kiszka
2010-09-13 7:51 ` Philippe Gerum
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.