All of lore.kernel.org
 help / color / mirror / Atom feed
From: Erich Focht <efocht@ess.nec.de>
To: linux-ia64@vger.kernel.org
Subject: [Linux-ia64] Re: O(1) scheduler fix for 2.5-ia64
Date: Tue, 05 Nov 2002 11:35:35 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709805333@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709805332@msgid-missing>

On Tuesday 05 November 2002 01:22, David Mosberger wrote:
> >>>>> On Mon, 4 Nov 2002 19:53:07 +0100, Erich Focht <efocht@ess.nec.de>
> >>>>> 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.
>
> 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



  reply	other threads:[~2002-11-05 11:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-05  0:22 [Linux-ia64] Re: O(1) scheduler fix for 2.5-ia64 David Mosberger
2002-11-05 11:35 ` Erich Focht [this message]
2002-11-05 18:54 ` David Mosberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ia64-105590709805333@msgid-missing \
    --to=efocht@ess.nec.de \
    --cc=linux-ia64@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.