From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C4929C49ED9 for ; Tue, 10 Sep 2019 22:33:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6DC7521019 for ; Tue, 10 Sep 2019 22:33:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=anarazel.de header.i=@anarazel.de header.b="U8iZasok"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="qJ0uMQmF" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725965AbfIJWdc (ORCPT ); Tue, 10 Sep 2019 18:33:32 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33991 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfIJWdb (ORCPT ); Tue, 10 Sep 2019 18:33:31 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 88F7921BF9; Tue, 10 Sep 2019 18:33:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 10 Sep 2019 18:33:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= date:from:to:cc:subject:message-id:mime-version:content-type; s= fm2; bh=XDXPs1E5Y1lR6vwfP96YiekAS/sJoRz/+A4CAEVd8tc=; b=U8iZasok ngvQDLcQdYwAcXNqcVQQRfq78Q7fVtBhtMwG84NX9yCk6DLdtG3AvQik2tTXilDe 0mfWGXSnTT3/GPyAe3Bltf4OGAW2OVpGypiEsb/Z+TFp4lCbSzT8I/to/nVyZXLc S/mNyd+YIavlPvKoZmBzUpeEmfv3CzqaZ4JNwPUQeijw00+VS2mXHHbzO77ucBtA 6k5zYetYzX1Df3SBsV7yBjH6h51zILvCFyh2Xa0hMLYbbXjjXWOI3/OrIkDpGdK4 gu5+ArILNTfKTZZq6Q6kraNs3UxcuG+QjjNukzZLtfl/QPtgLHg1U6yvcf6XFFjX 3ElwBwsUoKvWug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=XDXPs1E5Y1lR6vwfP96YiekAS/sJo Rz/+A4CAEVd8tc=; b=qJ0uMQmFOicFBryAnVHZtUdpFRsgWNLIM78ndidOOhTC7 YM0i83GExNMRBA5qzIEcztrbR/vns0HWGEumzBHjipemWX1Q2vzrPAcozM5fb9iq X38URdo9liAUEO6OVfo9vOepm5iy9Rvya+ZvRQpB6vuujWS2fn4wun7fAuh0mMtB czmuGOoHYDOBsvF+c3aQso4KS0yEgTvTse3xLTBdU4/22oDWd/MwhDz0DD2LxblU iMIvP0+vnylHpgR3p1nqJrwrKbJlqZahxJvftAAEP09a+dl9abSC8tcHDkLFYiUe Khb5n21zmHwjkPD75u/u5aNG1z1tnHh3iM0S6ys7Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtddugdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugesthdtredttddtvdenucfhrhhomheptehnughrvghsucfh rhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuffhomhgrihhnpe hkvghrnhgvlhdrohhrghenucfkphepudegkedrieelrdekhedrfeeknecurfgrrhgrmhep mhgrihhlfhhrohhmpegrnhgurhgvshesrghnrghrrgiivghlrdguvgenucevlhhushhtvg hrufhiiigvpedt X-ME-Proxy: Received: from intern.anarazel.de (unknown [148.69.85.38]) by mail.messagingengine.com (Postfix) with ESMTPA id 48EEF80059; Tue, 10 Sep 2019 18:33:28 -0400 (EDT) Date: Tue, 10 Sep 2019 15:33:27 -0700 From: Andres Freund To: Goldwyn Rodrigues Cc: linux-fsdevel@vger.kernel.org, jack@suse.com, hch@infradead.org Subject: Odd locking pattern introduced as part of "nowait aio support" Message-ID: <20190910223327.mnegfoggopwqqy33@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org Hi, Especially with buffered io it's fairly easy to hit contention on the inode lock, during writes. With something like io_uring, it's even easier, because it currently (but see [1]) farms out buffered writes to workers, which then can easily contend on the inode lock, even if only one process submits writes. But I've seen it in plenty other cases too. Looking at the code I noticed that several parts of the "nowait aio support" (cf 728fbc0e10b7f3) series introduced code like: static ssize_t ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from) { ... if (!inode_trylock(inode)) { if (iocb->ki_flags & IOCB_NOWAIT) return -EAGAIN; inode_lock(inode); } isn't trylocking and then locking in a blocking fashion an inefficient pattern? I.e. I think this should be if (iocb->ki_flags & IOCB_NOWAIT) { if (!inode_trylock(inode)) return -EAGAIN; } else inode_lock(inode); Obviously this isn't going to improve scalability to a very significant degree. But not unnecessarily doing two atomic ops on a contended lock can't hurt scalability either. Also, the current code just seems confusing. Am I missing something? Greetings, Andres Freund [1] https://lore.kernel.org/linux-block/20190910164245.14625-1-axboe@kernel.dk/