O(1) scheduler fix for 2.5-ia64
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Erich Focht
Erich> Hi David, this problem is wellknown and I actually thought Erich> that it was solved. But it looks like the complex Erich> prepare_arch_switch() etc. macros didn't make it into the 2.5 Erich> kernels for IA64. They are needed on IA64 because we have to Erich> release the runqueue lock during context switch. This is Erich> similar to sparc64. Thanks to John Hawks for noticing this.
Yes, this seems to have fallen through the cracks. Can you remind me what the deadlock scenario looked like?
--david
Quoted 10 lines · David Mosberger
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
On Mon, 4 Nov 2002 19:53:07 +0100, Erich Focht <[email protected]> said:
Erich> Hi David, this problem is wellknown and I actually thought Erich> that it was solved. But it looks like the complex Erich>
prepare_arch_switch()etc. macros didn't make it into the 2.5 Erich> kernels for IA64. They are needed on IA64 because we have to Erich> release the runqueue lock during context switch. This is Erich> similar to sparc64. Thanks to John Hawks for noticing this.
Quoted 2 lines
Yes, this seems to have fallen through the cracks. Can you remind me what the deadlock scenario looked like?
This can happen when the runqueue lock is held during a context switch which requires wrapping around the context numbers:
Example:
CPU#0:schedule()
-> spin_lock_irq(&rq->lock)
-> context_switch()
-> wrap_mmu_context()
-> read_lock(&tasklist_lock)CPU#1:sys_wait4() or release_task() or forget_original_parent()
-> write_lock(&tasklist_lock)
-> do_notify_parent()
-> wake_up_parent()
-> try_to_wake_up()
-> spin_lock_irq(&parent_rq->lock)If the parent's rq happens to be on CPU#0, we'll wait for the rq->lock of that CPU which will not be released, because there we wait for the tasklist_lock to become available.
Regards,
Erich
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line · Erich Focht
Erich> This can happen when the runqueue lock is held during a Erich> context switch which requires wrapping around the context Erich> numbers:
Ah, right. I really dislike the fact that the locking rules for platform-independent locks will vary from one platform to the other. Hopefully someone will look into fixing that at some point.
--david