Skip to contentSkip to conversation

O(1) scheduler fix for 2.5-ia64

Linux-ia64 David Mosberger 2 participants 3 messages Nov 5, 2002

lore
Share & tools
lore
#0 lore raw
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
#1 lore raw
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

#2 lore raw
In reply to David Mosberger
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