linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Davidlohr Bueso <dave@stgolabs.net>
To: tglx@linutronix.de, pbonzini@redhat.com
Cc: bigeasy@linutronix.de, peterz@infradead.org, rostedt@goodmis.org,
	torvalds@linux-foundation.org, will@kernel.org,
	joel@joelfernandes.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, dave@stgolabs.net,
	Davidlohr Bueso <dbueso@suse.de>
Subject: [PATCH 4/4] sched/swait: Reword some of the main description
Date: Mon, 23 Mar 2020 21:44:53 -0700	[thread overview]
Message-ID: <20200324044453.15733-5-dave@stgolabs.net> (raw)
In-Reply-To: <20200324044453.15733-1-dave@stgolabs.net>

With both the increased use of swait and kvm no longer using
it, we can reword some of the comments. While removing Linus'
valid rant, I've also cared to explicitly mention that swait
is very different than regular wait. In addition it is
mentioned against using swait in favor of the regular flavor.

Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
---
 include/linux/swait.h | 23 +++++------------------
 1 file changed, 5 insertions(+), 18 deletions(-)

diff --git a/include/linux/swait.h b/include/linux/swait.h
index 73e06e9986d4..6e5b5d0e64fd 100644
--- a/include/linux/swait.h
+++ b/include/linux/swait.h
@@ -9,23 +9,10 @@
 #include <asm/current.h>
 
 /*
- * BROKEN wait-queues.
- *
- * These "simple" wait-queues are broken garbage, and should never be
- * used. The comments below claim that they are "similar" to regular
- * wait-queues, but the semantics are actually completely different, and
- * every single user we have ever had has been buggy (or pointless).
- *
- * A "swake_up_one()" only wakes up _one_ waiter, which is not at all what
- * "wake_up()" does, and has led to problems. In other cases, it has
- * been fine, because there's only ever one waiter (kvm), but in that
- * case gthe whole "simple" wait-queue is just pointless to begin with,
- * since there is no "queue". Use "wake_up_process()" with a direct
- * pointer instead.
- *
- * While these are very similar to regular wait queues (wait.h) the most
- * important difference is that the simple waitqueue allows for deterministic
- * behaviour -- IOW it has strictly bounded IRQ and lock hold times.
+ * Simple waitqueues are semantically very different to regular wait queues
+ * (wait.h). The most important difference is that the simple waitqueue allows
+ * for deterministic behaviour -- IOW it has strictly bounded IRQ and lock hold
+ * times.
  *
  * Mainly, this is accomplished by two things. Firstly not allowing swake_up_all
  * from IRQ disabled, and dropping the lock upon every wakeup, giving a higher
@@ -39,7 +26,7 @@
  *    sleeper state.
  *
  *  - the !exclusive mode; because that leads to O(n) wakeups, everything is
- *    exclusive.
+ *    exclusive. As such swake_up_one will only ever awake _one_ waiter.
  *
  *  - custom wake callback functions; because you cannot give any guarantees
  *    about random code. This also allows swait to be used in RT, such that
-- 
2.16.4


      parent reply	other threads:[~2020-03-24  4:46 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-24  4:44 [PATCH -tip 0/4] kvm: Use rcuwait for vcpu blocking Davidlohr Bueso
2020-03-24  4:44 ` [PATCH 1/4] rcuwait: Fix stale wake call name in comment Davidlohr Bueso
2020-03-24  4:44 ` [PATCH 2/4] rcuwait: Let rcuwait_wake_up() return whether or not a task was awoken Davidlohr Bueso
2020-03-24  4:44 ` [PATCH 3/4] kvm: Replace vcpu->swait with rcuwait Davidlohr Bueso
2020-03-24 12:07   ` kbuild test robot
2020-03-24 16:47   ` kbuild test robot
2020-03-24 17:56     ` Davidlohr Bueso
2020-03-25 17:09   ` Paolo Bonzini
2020-04-14 21:12     ` Davidlohr Bueso
2020-04-15 12:11       ` Paolo Bonzini
2020-04-20 16:41   ` [PATCH v2] " Davidlohr Bueso
2020-04-20 17:12     ` Marc Zyngier
2020-04-20 17:25       ` Paolo Bonzini
2020-04-20 20:56       ` Davidlohr Bueso
2020-04-20 21:04         ` Paolo Bonzini
2020-04-20 21:50           ` Davidlohr Bueso
2020-04-21  9:43             ` Paolo Bonzini
2020-04-21 18:07               ` Davidlohr Bueso
2020-04-21 19:52                 ` Paolo Bonzini
2020-03-24  4:44 ` Davidlohr Bueso [this message]

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=20200324044453.15733-5-dave@stgolabs.net \
    --to=dave@stgolabs.net \
    --cc=bigeasy@linutronix.de \
    --cc=dbueso@suse.de \
    --cc=joel@joelfernandes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).