All of lore.kernel.org
 help / color / mirror / Atom feed
From: Scott Long <scott@swiftview.com>
To: linux-kernel@vger.kernel.org
Subject: Re: wake_up vs. wake_up_sync
Date: Wed, 27 Jun 2001 14:57:43 -0700	[thread overview]
Message-ID: <3B3A56D7.90544D15@swiftview.com> (raw)
In-Reply-To: <3B3A4E8B.E4301909@colorfullife.com>

Does reschedule_idle() ever cause the current CPU to get scheduled? That
is, if someone calls wake_up() and wakes up a higher-priority process
could reschedule_idle() potentially immediately switch the current CPU
to that higher-priority process?

Because this is NOT what I want to happen (it would produce a deadlock
in this particular situation). Having other CPUs get scheduled is ok,
but having the process that called wake_up() get kicked out would be
very bad. In that case I suppose I will have to use wake_up_sync().

Would the following be an appropriate solution?

{
    wake_up_sync(&wq->q);

    /* Potential deadlock situation */
    user_unlock(&wq->lock);

    /* Potential for deadlock has passed */
    reschedule_idle();
}

Thanks,
Scott

Manfred Spraul wrote:
> 
> > I'm having trouble understanding the difference between these.
> > Synchronous apparently causes try_to_wake_up() to NOT call
> > reschedule_idle() but I'm uncertain what reschedule_idle() is doing. I
> > assume it just looks for an idle CPU and makes that CPU reschedule.
> >
> > What is the purpose of wake_up_sync?
> 
> Avoid the reschedule_idle() call - it's quite costly, and it could cause
> processes jumping from one cpu to another.
> 
> > Why would you want to prevent
> > reschedule_idle()?
> >
> If one process runs, wakes up another process and _knows_ that it's
> going to sleep immediately after the wake_up it doesn't need the
> reschedule_idle: the current cpu will be idle soon, the scheduler
> doesn't need to find another cpu for the woken up thread.
> 
> I think the pipe code is the only user of _sync right now - pipes cause
> an incredible amount of task switches.
> 
> --
>         Manfred

  parent reply	other threads:[~2001-06-27 22:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-06-27 21:22 wake_up vs. wake_up_sync Manfred Spraul
2001-06-27 21:38 ` Mike Kravetz
2001-06-27 22:41   ` Manfred Spraul
2001-06-27 21:57 ` Scott Long [this message]
2001-06-27 22:40   ` Mike Kravetz
  -- strict thread matches above, loose matches on Subject: below --
2001-06-28  2:54 Hubertus Franke
2001-06-27 20:18 Scott Long

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=3B3A56D7.90544D15@swiftview.com \
    --to=scott@swiftview.com \
    --cc=linux-kernel@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.