Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp294549ybz; Tue, 21 Apr 2020 21:16:00 -0700 (PDT) X-Google-Smtp-Source: APiQypI9edPiICG7keVGihbxqxfBMJLPT17AzN6qsJK/ML7tOK0esNuUmlebQ9aw/FsqP0AM9rS8 X-Received: by 2002:a17:906:f106:: with SMTP id gv6mr25106878ejb.271.1587528960292; Tue, 21 Apr 2020 21:16:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587528960; cv=none; d=google.com; s=arc-20160816; b=axIMpAMt6LKqid50JIZx2pzkPBgeVZ1UZSUHHDoMPeYqsbgTWwZ7CTArm3rrYPxbGZ vlUFfPQqc6qNvLg8P7rBuuEwPEtsRGYHRdUGex1Iuk6qn0N3dFMsuLblMygMUsBHcYK8 65Ss25kqrj15BMbPbio33qhURxIrKPk6nDNHv542v1KlP57unEnM4jOskjjqHPajOBRT yb52sHJpAr99i0NXRM+X8S+tODd7ZhCMM9Ndu9lFfXtdrTE/vaXXiocpyUTpM/F8Bfaj z+i9Cz2PqXqTaFz9G/8EfqlVgkZkLG+mbwaXJMyag2PsUiTbS+TNe09snIy7q7vWmQ25 sV0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=d8g3aTNXNDWeaLYkFL8Hs31n//czo08kEKgyRAfiZzQ=; b=inTZn45ewR2zLi71EU13n4kwe/F4sWAAz1Tb2fye4AOOJcBa0Hmu4PPFAsxiolMAa3 kZNf/PFodkreiEzMK9YKKsz34OY5pdeDOOcnzbZ4MA3bRXCu3Q2wzbr6Qp5lHovuWbWo VFeCblgcbxfIjdfKVKPTonhqM8vIZwJ0DFXczQkiAf7eO8D/t1XUKs2eoO6lI9lqxUOH yCenpBRI0YLwwg0mF0zw2BtNojBg8VdIcktIWF+DWEihg1htVvWDe4/NvQ7+qu1AN1fN bqPCNbkCpuaDSQmRXbpXt1/1r/asn2lq5SSWcbGTbSY94DXINrGNORmFrp0XVqBIASVd O+sA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id cw10si2800807ejb.369.2020.04.21.21.15.38; Tue, 21 Apr 2020 21:16:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726537AbgDVEMA (ORCPT + 99 others); Wed, 22 Apr 2020 00:12:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:60174 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726494AbgDVEL6 (ORCPT ); Wed, 22 Apr 2020 00:11:58 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 1E94DAE6E; Wed, 22 Apr 2020 04:11:55 +0000 (UTC) From: Davidlohr Bueso 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 Subject: [PATCH 5/5] sched/swait: Reword some of the main description Date: Tue, 21 Apr 2020 21:07:39 -0700 Message-Id: <20200422040739.18601-6-dave@stgolabs.net> X-Mailer: git-send-email 2.16.4 In-Reply-To: <20200422040739.18601-1-dave@stgolabs.net> References: <20200422040739.18601-1-dave@stgolabs.net> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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..6a8c22b8c2a5 100644 --- a/include/linux/swait.h +++ b/include/linux/swait.h @@ -9,23 +9,10 @@ #include /* - * 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