From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="io4uKolV" Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BBAF6D40 for ; Thu, 30 Nov 2023 12:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701377012; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cNAnS8dhB7e4TvDt7MCxzeAFcs3pq2oyNt9JbDuu0+0=; b=io4uKolVR4VJ8r7LStCfXRLprNmnn/jKOqo6bkJNimWSxOjS7kko5EnHb+xFK56EWtDhjl 8zZmVTFw9NnKubGcxyIY38AkA0z/jmJ/DNCD+9oDRkww9TSs13puw4MYF4zClj44cGAEDj IMgmPUjWYZPViRD0fdqGPqRacV0urpI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-381-AdaJfscqMBiZ56tclMt4ww-1; Thu, 30 Nov 2023 15:43:29 -0500 X-MC-Unique: AdaJfscqMBiZ56tclMt4ww-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 12D5085A58A; Thu, 30 Nov 2023 20:43:29 +0000 (UTC) Received: from localhost (unknown [10.39.192.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id E5D84C0BDC0; Thu, 30 Nov 2023 20:43:26 +0000 (UTC) Date: Thu, 30 Nov 2023 15:43:25 -0500 From: Stefan Hajnoczi To: Peter Xu Cc: qemu-devel@nongnu.org, Jean-Christophe Dubois , Fabiano Rosas , qemu-s390x@nongnu.org, Song Gao , Marcel Apfelbaum , Thomas Huth , Hyman Huang , Marcelo Tosatti , David Woodhouse , Andrey Smirnov , Peter Maydell , Kevin Wolf , Ilya Leoshkevich , Artyom Tarasenko , Mark Cave-Ayland , Max Filippov , Alistair Francis , Paul Durrant , Jagannathan Raman , Juan Quintela , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , qemu-arm@nongnu.org, Jason Wang , Gerd Hoffmann , Hanna Reitz , =?iso-8859-1?Q?Marc-Andr=E9?= Lureau , BALATON Zoltan , Daniel Henrique Barboza , Elena Ufimtseva , Aurelien Jarno , Hailiang Zhang , Roman Bolshakov , Huacai Chen , Fam Zheng , Eric Blake , Jiri Slaby , Alexander Graf , Liu Zhiwei , Weiwei Li , Eric Farman , Stafford Horne , David Hildenbrand , Markus Armbruster , Reinoud Zandijk , Palmer Dabbelt , Cameron Esfahani , xen-devel@lists.xenproject.org, Pavel Dovgalyuk , qemu-riscv@nongnu.org, Aleksandar Rikalo , John Snow , Sunil Muthuswamy , Michael Roth , David Gibson , "Michael S. Tsirkin" , Richard Henderson , Bin Meng , Stefano Stabellini , kvm@vger.kernel.org, qemu-block@nongnu.org, Halil Pasic , Anthony Perard , Harsh Prateek Bora , Alex =?iso-8859-1?Q?Benn=E9e?= , Eduardo Habkost , Paolo Bonzini , Vladimir Sementsov-Ogievskiy , =?iso-8859-1?Q?C=E9dric?= Le Goater , qemu-ppc@nongnu.org, Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= , Christian Borntraeger , Akihiko Odaki , Leonardo Bras , Nicholas Piggin , Jiaxun Yang Subject: Re: [PATCH 1/6] system/cpus: rename qemu_mutex_lock_iothread() to qemu_bql_lock() Message-ID: <20231130204325.GE1184658@fedora> References: <20231129212625.1051502-1-stefanha@redhat.com> <20231129212625.1051502-2-stefanha@redhat.com> Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SBmcOIqLLg4zQdMA" Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.8 --SBmcOIqLLg4zQdMA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 30, 2023 at 03:08:49PM -0500, Peter Xu wrote: > On Wed, Nov 29, 2023 at 04:26:20PM -0500, Stefan Hajnoczi wrote: > > The Big QEMU Lock (BQL) has many names and they are confusing. The > > actual QemuMutex variable is called qemu_global_mutex but it's commonly > > referred to as the BQL in discussions and some code comments. The > > locking APIs, however, are called qemu_mutex_lock_iothread() and > > qemu_mutex_unlock_iothread(). > >=20 > > The "iothread" name is historic and comes from when the main thread was > > split into into KVM vcpu threads and the "iothread" (now called the main > > loop thread). I have contributed to the confusion myself by introducing > > a separate --object iothread, a separate concept unrelated to the BQL. > >=20 > > The "iothread" name is no longer appropriate for the BQL. Rename the > > locking APIs to: > > - void qemu_bql_lock(void) > > - void qemu_bql_unlock(void) > > - bool qemu_bql_locked(void) > >=20 > > There are more APIs with "iothread" in their names. Subsequent patches > > will rename them. There are also comments and documentation that will be > > updated in later patches. > >=20 > > Signed-off-by: Stefan Hajnoczi >=20 > Acked-by: Peter Xu >=20 > Two nickpicks: >=20 > - BQL contains "QEMU" as the 2nd character, so maybe easier to further > rename qemu_bql into bql_? Philippe wondered whether the variable name should end with _mutex (or _lock is common too), so an alternative might be big_qemu_lock. That's imperfect because it doesn't start with the usual qemu_ prefix. qemu_big_lock is better in that regard but inconsistent with our BQL abbreviation. I don't like putting an underscore at the end. It's unusual and would make me wonder what that means. Naming is hard, but please discuss and I'm open to change to BQL variable's name to whatever we all agree on. >=20 > - Could we keep the full spell of BQL at some places, so people can sti= ll > reference it if not familiar? IIUC most of the BQL helpers will root > back to the major three functions (_lock, _unlock, _locked), perhaps > add a comment of "BQL stands for..." over these three functions as > comment? Yes, I'll update the doc comments to say "Big QEMU Lock (BQL)" for each of these functions. Stefan --SBmcOIqLLg4zQdMA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhpWov9P5fNqsNXdanKSrs4Grc8gFAmVo8+0ACgkQnKSrs4Gr c8jJmAf9E8P/Xu7G6FqCGvOsGt/mlsqbLE31vNsiYxVDEuJJ4a39lBYM8XOY3zUI Gg064yxhG8tJGG9m/NXlySw6Sspev3/nD4NPnrVvUGbS7OGjFL9L4oeHzgeK/ude U2mtVSBxhVHvx08ya0nKtF3i0ghiSWa+/X83V03smz5ZuMNU1ZXTAzSCp54dwQCH nO4Q4Y7nQxE57jSy8rB5HTwxFpmfjfXlzYpF+3rYGj+pjy7vOEuD8jdGBZ3+ts9x Cca0JUsQNEHbcUesyE4ToH5KQHOFUQKalbc+knFcT8JuoGXX3MwuS4mp22wi7Gv6 LDSh2bymbDqhY4xQU5BomaihozS0ww== =QeIi -----END PGP SIGNATURE----- --SBmcOIqLLg4zQdMA--