| |
|
 |
|
 |
|
|
|
| |
|
|
xen-ia64-devel
[Xen-ia64-devel] Re: Any hint about a weird behavior about scheduler?
On 25 Jan 2006, at 03:36, Tian, Kevin wrote:
The possible reason seems from your recent change to reduce lock
critical region in __enter_scheduler, where spin_unlock_irq is promoted
to the point before context_switch. That's obvious good, however to
leave a small window with interrupt enabled which may not be handled
correctly by current ia64 code. To move spin_unlock_irq backward after
context_switch, everything works well then.
So Keir, have you seen any similar phenomenon per your
experience before? If yes, how about the cause? That may be different
as
IA64, which however provide invaluable hint to help track down bogus
code on IA64.
I haven't seen this on x86. My gut feeling is that perhaps you are
executing softirq work Linux style rather than Xen style.
That is: Linux is happy to execute softirq work at the tail of a
hardirq, as long as it is the outermost hardirq context. In contrast,
Xen expects softirqs only to be executed in the outermost Xen
activation. So, for example, Xen does not check for softirq reentrancy
in do_softirq, because that is never expected to happen. But even if
you did add a reentrancy check you would risk deadlock (since you may
interrupt e.g., hypercall context while it has a lock held, and that
lock may be shared with code that is executed in softirq context).
Removing do_softirq() from irq_exit() will probably fix this problem
for you, and generally improve correctness.
-- Keir
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
|
|
| |
|
Home