From nobody Wed Nov 27 04:58:49 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1701287794; cv=none; d=zohomail.com; s=zohoarc; b=ZlnPc7w5FcEUkcVWCpAlGEDQDGt/VxvX9o3r1PWTilL4ErdB7NyqgY3/mar0cZx14ZCN6et8cDRKH82IL1sfS2XJk6hHh6Bt2d+W8CNldykTqo5x2SgBlVRwOn95USuMlYub2zr4ULYCXRDTmb6oBE1GZ+o0tfSo7hBonFvsKtk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1701287794; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=jC9wKpUncUXW/n39IkHJZO19bmqglRHH0XTJO58TB7M=; b=TQef9cN/HxqsLKEKqa9dliFXRsljQjnpyFzkdMxzWmXA8Os5ldPhbx2F5T4ZfkYNQ6Y8Vc3um+7MPY3isy5mA1LUer57/tM9d75gWnvD2rnKE9C1kbjS0qvEbNXNIg/j0A1g2bNJXsxOCQ1Sb4NIfzFARxL+Oo2VBRreV9sXrMM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1701287794220870.9038205848398; Wed, 29 Nov 2023 11:56:34 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.644178.1004901 (Exim 4.92) (envelope-from ) id 1r8QfQ-0001Mv-4k; Wed, 29 Nov 2023 19:56:16 +0000 Received: by outflank-mailman (output) from mailman id 644178.1004901; Wed, 29 Nov 2023 19:56:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r8QfQ-0001Mk-0u; Wed, 29 Nov 2023 19:56:16 +0000 Received: by outflank-mailman (input) for mailman id 644178; Wed, 29 Nov 2023 19:56:15 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r8QfP-0000tx-4h for xen-devel@lists.xenproject.org; Wed, 29 Nov 2023 19:56:15 +0000 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 590d486a-8ef1-11ee-9b0f-b553b5be7939; Wed, 29 Nov 2023 20:56:13 +0100 (CET) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-27-8eQxkhYyPXOHpZ0VJZcoIw-1; Wed, 29 Nov 2023 14:56:07 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (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 18C2529AA2C8; Wed, 29 Nov 2023 19:56:06 +0000 (UTC) Received: from localhost (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4111440C6EBA; Wed, 29 Nov 2023 19:56:04 +0000 (UTC) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 590d486a-8ef1-11ee-9b0f-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701287772; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jC9wKpUncUXW/n39IkHJZO19bmqglRHH0XTJO58TB7M=; b=Lpi+SiAtSWuTmpoXJbO+6lSa4GnAe28qlTAsv5NXY9pQYLc/VNr4FfFmmd5TczqmcbL9Pj u6NkrkXTwaK1ZdF100ZhC9MqBs4EXOunQbxA3A96+XPXgEJecS8NSvF+HRQuGIe1sv8wti wH6uak60qFXHcqBiLjSsTPeFB8ke+m4= X-MC-Unique: 8eQxkhYyPXOHpZ0VJZcoIw-1 From: Stefan Hajnoczi To: qemu-devel@nongnu.org Cc: Hanna Reitz , Paul Durrant , Paolo Bonzini , Alberto Garcia , Emanuele Giuseppe Esposito , John Snow , Kevin Wolf , Eric Blake , Wen Congyang , , xen-devel@lists.xenproject.org, Coiby Xu , Stefan Hajnoczi , Eduardo Habkost , Xie Changlong , Ari Sundholm , Li Zhijian , Cleber Rosa , Juan Quintela , "Michael S. Tsirkin" , =?UTF-8?q?Daniel=20P=2E=20Berrang=C3=A9?= , Jason Wang , Vladimir Sementsov-Ogievskiy , Zhang Chen , Peter Xu , Anthony Perard , Stefano Stabellini , Leonardo Bras , Pavel Dovgalyuk , Fam Zheng , Fabiano Rosas Subject: [PATCH 03/12] aio: make aio_context_acquire()/aio_context_release() a no-op Date: Wed, 29 Nov 2023 14:55:44 -0500 Message-ID: <20231129195553.942921-4-stefanha@redhat.com> In-Reply-To: <20231129195553.942921-1-stefanha@redhat.com> References: <20231129195553.942921-1-stefanha@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1701287794329000003 Content-Type: text/plain; charset="utf-8" aio_context_acquire()/aio_context_release() has been replaced by fine-grained locking to protect state shared by multiple threads. The AioContext lock still plays the role of balancing locking in AIO_WAIT_WHILE() and many functions in QEMU either require that the AioContext lock is held or not held for this reason. In other words, the AioContext lock is purely there for consistency with itself and serves no real purpose anymore. Stop actually acquiring/releasing the lock in aio_context_acquire()/aio_context_release() so that subsequent patches can remove callers across the codebase incrementally. I have performed "make check" and qemu-iotests stress tests across x86-64, ppc64le, and aarch64 to confirm that there are no failures as a result of eliminating the lock. Signed-off-by: Stefan Hajnoczi Acked-by: Kevin Wolf Reviewed-by: Eric Blake --- util/async.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/util/async.c b/util/async.c index 8f90ddc304..04ee83d220 100644 --- a/util/async.c +++ b/util/async.c @@ -725,12 +725,12 @@ void aio_context_unref(AioContext *ctx) =20 void aio_context_acquire(AioContext *ctx) { - qemu_rec_mutex_lock(&ctx->lock); + /* TODO remove this function */ } =20 void aio_context_release(AioContext *ctx) { - qemu_rec_mutex_unlock(&ctx->lock); + /* TODO remove this function */ } =20 QEMU_DEFINE_STATIC_CO_TLS(AioContext *, my_aiocontext) --=20 2.42.0