From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E91420ED for ; Wed, 15 Jan 2025 00:28:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736900939; cv=none; b=ZOFYWI/gC3YyRy29YtYVS3dA/h9CK9jOxAAF6Y+OwZvJJkpFB645zS1LHcuE6y3kGBeXPkGnF5xyH/fmH87khWPSepKnuL5lmZzCCGyco/KRkXvrBVrWj5A03vgYfO3/qPF4bBmB0ktZPWN8i8zXJFYJk/KibLR1lM7qGmk7Cao= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736900939; c=relaxed/simple; bh=4wL9BblJwVc29y5rrqfOUTAGMw5lMx+hGvhBssriTnw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uLhfn/bYJs6Eowc4inot4MbFolQaUT1Fb8f1ogkLMqKw4MzL4jB5Y2c9addVW2a/manZWLc01LM/PyeYjPO4lLfPT34iYkEB1U4VVqi3TgoVcLLdk7+gM0WMY+p2fo+YauNJ9ADjzrjP12rH8mt5XGjXLlLD9a4qqwBABHhuXAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=cXbRy9Uk; arc=none smtp.client-ip=209.85.216.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="cXbRy9Uk" Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2eed82ca5b4so10130148a91.2 for ; Tue, 14 Jan 2025 16:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1736900937; x=1737505737; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=lYtpoL9EibYd/5yE+lBzA+DrtKubT0uHHdBjBr+3TSU=; b=cXbRy9Ukpn0QWh0hzH9E1YCjGPHSJg8i0yENlE8ZjDAxd/DY80BHeXVzdudmjxu2h/ +E8yXKaBw52ScRpQe6O37ipUVlv2bosn63KpBaC3RElZwqfZThi9Fa1YdAU1VvY+ZaGV 0nXblhcGk2uxduIPfZ51sbWNTAnYCYnCGcROIE3a9PEnb0H7C9XEIboS+au66kZmEp11 4TUuTnqfrTZedG7Ge0d6KDyCGsw0eMHEaRgvGVDu6hBYnSECOo6iyicq+2bkXd+M4J/l L4pVL7sKnoVCGYTN3963f1E7CnDevX9ngSGKjEGy1OEnZ8zUBav4BDvcTDqWNPXEA7zx d5Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736900937; x=1737505737; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=lYtpoL9EibYd/5yE+lBzA+DrtKubT0uHHdBjBr+3TSU=; b=vkl24Je1iR1cHSuyFmQKumlycYkxPrzdIgghs3OBsXuKyYzOMhW5mMF2ZZliJH1sCl 8/pGbam2qPR332Kz21acL2Dufr90FN5cyvGhzFSNuUxzC692G0BoKOSlHRABtR9aWod5 mKQhDFh7H0qx2YpAF+i9SspaZarhlWRjJPJuCniLeSWgcrasvbxA7lXSzqAu9JzAhxQa JvcSQG6DGFr4x3M4wHygCFLlDvL/99lJm/PFrR+6Ym1+Bffw2TB9zkeVLae/zMio25QV G2Md+zzDpZ6TeeAxNyq/EMPgIRJzJ0D6G2t4hy7eiSyxCRvqGu54O2SS6GQFn7l+BpEn d4DA== X-Forwarded-Encrypted: i=1; AJvYcCVpe1BEPql0dtAVMHmemMSWPdfrpuixezjH2sM/3I7bUKgUQWTu11yW576YTd7hHmSrMzK+UdwtkovDuco=@vger.kernel.org X-Gm-Message-State: AOJu0YyUN/GRBN0V1dj8Xlm6FBlGEYpkrs2jqGhgantLrmo0kEG4FRIW rJzh30ccKDko+oSTZL1tgbwdEjr1AeZBLam1Me2zhaJBZ8TGquj77DJqeslpteI= X-Gm-Gg: ASbGncvR3H0OUW9WP5vgxJy3ldm6aoDYqPdyukl2WqRzs6pyMcZuhb4vKIfJtZeSLLc 7gC3fzdnLh7gBrs6CGZJUoK5OkJJcXYYaaZYNVzQIA4Gr+J7kbY7XWAVCCBfGwxQsmL3lTBMOHB /pqVv6oMMCsF7Tr2ccIb0e7EH29RMOUIQzi7mz6nHw9jfRCIAekw0JDo49jJMLrEFxy0liW/GKY 0Ez5to5MT1SqBfPgkPjYvH4aVH5EoPR2q0XF6Sm6/9ZOgkumJTFGvQ3J07LSidqbZW2fRE+oWyC 5Y2AtkuZNLa1g+PixxETIA== X-Google-Smtp-Source: AGHT+IGb+3R4BSWThIWHu00rojTXaCH8qdvGC7yoxLKQgMAcSJfD0FT+zDIh358sie79C0Ktcsfn8w== X-Received: by 2002:a17:90b:2e86:b0:2ee:b26c:10a0 with SMTP id 98e67ed59e1d1-2f5490abf24mr42449277a91.24.1736900937466; Tue, 14 Jan 2025 16:28:57 -0800 (PST) Received: from dread.disaster.area (pa49-186-89-135.pa.vic.optusnet.com.au. [49.186.89.135]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2f72c2bb2cdsm136495a91.34.2025.01.14.16.28.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 16:28:56 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.98) (envelope-from ) id 1tXrHC-00000005y5b-21sD; Wed, 15 Jan 2025 11:28:54 +1100 Date: Wed, 15 Jan 2025 11:28:54 +1100 From: Dave Chinner To: Jinliang Zheng Cc: chandan.babu@oracle.com, djwong@kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, flyingpeng@tencent.com, Jinliang Zheng Subject: Re: [PATCH] xfs: using mutex instead of semaphore for xfs_buf_lock() Message-ID: References: <20241219171629.73327-1-alexjlzheng@tencent.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241219171629.73327-1-alexjlzheng@tencent.com> On Fri, Dec 20, 2024 at 01:16:29AM +0800, Jinliang Zheng wrote: > xfs_buf uses a semaphore for mutual exclusion, and its count value > is initialized to 1, which is equivalent to a mutex. > > However, mutex->owner can provide more information when analyzing > vmcore, making it easier for us to identify which task currently > holds the lock. However, the buffer lock also protects the buffer state and contents whilst IO id being performed and it *is not owned by any task*. A single lock cycle for a buffer can pass through multiple tasks before being unlocked in a different task to that which locked it: p0 xfs_buf_lock() ... ..... queued to workqueue ..... perform IO completion xfs_buf_unlock() IOWs, the buffer lock here prevents any other task from accessing and modifying the contents/state of the buffer until the IO in flight is completed. i.e. the buffer contents are guaranteed to be stable during write IO, and unreadable when uninitialised during read IO.... i.e. the locking model used by xfs_buf objects is incompatible with the single-owner-task critical section model implemented by mutexes... -Dave. -- Dave Chinner david@fromorbit.com