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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4C89C54E49 for ; Mon, 26 Feb 2024 01:32:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4D4586B0127; Sun, 25 Feb 2024 20:32:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4846B6B0129; Sun, 25 Feb 2024 20:32:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 372E86B012A; Sun, 25 Feb 2024 20:32:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 283386B0127 for ; Sun, 25 Feb 2024 20:32:36 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AD0A51A0188 for ; Mon, 26 Feb 2024 01:32:35 +0000 (UTC) X-FDA: 81832230270.18.2075E5A Received: from mail-ed1-f48.google.com (mail-ed1-f48.google.com [209.85.208.48]) by imf28.hostedemail.com (Postfix) with ESMTP id BB3F6C0002 for ; Mon, 26 Feb 2024 01:32:33 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=IhSRfPsy; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708911153; a=rsa-sha256; cv=none; b=GreGp+QPi2dEZ03//bGuxhq4OwFkxTLfwOaIYNgt65s4EI4XJr/s2UbIHNw93HHHl04knB wRvgHms6y40pBp2rUUm0HyhlUXZ5oY3p8Zai0ViJGmFE9F1ykhdT2x6v8KZq81eRqLiUe0 QteHin3cEi9pEdKi3IJztyOc3bQUlUY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=IhSRfPsy; dmarc=none; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.48 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708911153; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=LfKdOZfWTbECMYEk3NyBPikBNb6uqGRUe057sifTtwc=; b=MFu75++SywYqj6Pl2OxUMYwZrIIwJUcVg1O4AGtYPYLjh1bNbx/R5GBINthEEI25GYA5in THe7MD6QeQbS67DUrgXE5ei9jwGTuTt9gnnpiCH1WYcGVJ3N2zKVMC8p8lch5ykemMLr/U 1pShKg6eMa04KgGaJWKlVn/4WfBhevI= Received: by mail-ed1-f48.google.com with SMTP id 4fb4d7f45d1cf-5649c25369aso3131898a12.2 for ; Sun, 25 Feb 2024 17:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1708911152; x=1709515952; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=LfKdOZfWTbECMYEk3NyBPikBNb6uqGRUe057sifTtwc=; b=IhSRfPsyBtyg+xEAJDKD2ooBIbKUKuUUYXFBBmdOzfAibaH+mhfq6n131fUXjYbkGH plV9j5QCrvN1ZHw7ak4Ce0DluhkOhENaZ7il3t9khtpbAAoPeP7yyTc+B1FkM8awYSiA uObDB8pVcNTXhn+2Uv8C0Th9mAU2FBURKB8Zg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708911152; x=1709515952; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LfKdOZfWTbECMYEk3NyBPikBNb6uqGRUe057sifTtwc=; b=fR1s+DfgiRoIgNky2wcP+tep56yv/G4hBcN/HGmURpiNBKdwLcjA0f5TXcU9DhYx+v 1BZW3y9LpESMIbdwGN2Y3CDTdlo8VnD1RVp+Mk8lIIBd+NlszC/1QBGTSjBEwVj5NEvb BInDp0DhxK9PRoXadsfiMyXcDAp+M0KJ1fodSN5FUea2W6tVySElx4g9r40Hpt/U/Ce5 Wu+qVV0TdzyNGSn+/lOpMsg4oSIVYF1HRRJGGkkaRlxl7Rw0+b4KzXSrJRgCTtLnelAg jwE/Ezl+ZuVw/xNNYONd6WA87KnRi2CgZ9xG40thbRaQ0zyqCBRGNG8uopWyYtP6UGHC P6Lg== X-Forwarded-Encrypted: i=1; AJvYcCUsT4UgswUoD8LEPAvmA4XFMuOo7i0jtAgSfI0nMl6HUbWZ16lfWLKQZWN611SRrGze9WANl/YAQrHC6Q0Lsr+bSMY= X-Gm-Message-State: AOJu0YynNcSHvDAl3mnxgpJZpbJpCXTf2QUEQc23u904rDmmE6i26Pd0 Z9Y1uLYo6mRM49rdzA5m5lVtcyEIRgFwczmojtfyBlOkdU631DUmdZK2KK4u202xcCNMX3vQcKk 7rcxyFQ== X-Google-Smtp-Source: AGHT+IEOAHYLR1ZrDHl5WthY1bZJTDoCxLQROk/q8NDvrbbP187OncjYpiTYXyAz2FgVJleUiJf5Cg== X-Received: by 2002:a17:906:1392:b0:a43:68b:6a29 with SMTP id f18-20020a170906139200b00a43068b6a29mr2308927ejc.46.1708911151834; Sun, 25 Feb 2024 17:32:31 -0800 (PST) Received: from mail-ej1-f45.google.com (mail-ej1-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id rf22-20020a1709076a1600b00a433e8cfb7esm723309ejc.64.2024.02.25.17.32.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 25 Feb 2024 17:32:31 -0800 (PST) Received: by mail-ej1-f45.google.com with SMTP id a640c23a62f3a-a43488745bcso60736866b.3 for ; Sun, 25 Feb 2024 17:32:31 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCV7Dkt4wx1Pv6uZ2FGpXekWpZJi+y0OVufyubfOX1BZ0lapyuKbxc6ZfAySa76+utKUR2UUS8VdTzIRituVbeap6Xc= X-Received: by 2002:a17:906:3c4d:b0:a3f:ab4d:f7e3 with SMTP id i13-20020a1709063c4d00b00a3fab4df7e3mr3051531ejg.0.1708911150763; Sun, 25 Feb 2024 17:32:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Linus Torvalds Date: Sun, 25 Feb 2024 17:32:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Measuring limits and enhancing buffered IO To: Kent Overstreet Cc: Matthew Wilcox , Luis Chamberlain , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm , Daniel Gomez , Pankaj Raghav , Jens Axboe , Dave Chinner , Christoph Hellwig , Chris Mason , Johannes Weiner Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BB3F6C0002 X-Stat-Signature: qx8nwrg84mnedrgx54oqm9rtrnzcryz9 X-HE-Tag: 1708911153-930875 X-HE-Meta: U2FsdGVkX1/j5mWPOYYRvlAKTlcjVlh1MhX5UBQrnF9+hSgH8/87fPn82wr5jMC2BNWCJfRk4PU/uvM72pTw1b1GuIoIRhNDN9v/z4OHoPtNOY36N21JDHCZAZRjAZZ9sQITAzpJ/hM3ElvZfWEwogQ/iAnvsB6a2+YGpytVJyxy2cVb/gnSZFKmlC4wj6DxJoep6xR3VIavxgcGi7mSJPbZENQFK3b/tJv8N4VSGZ040+IkEmwaw7eqHXridy06EK3mBw2oJcxEfkEYvr1aWBAuw/YtOAHor5ZCPWSO+tnFwCcAvYW9lwgQ/9lQ9DAeIu5bsALQ5+JuIo3izzsCtTBMLKVyhRYYiYSVUJNIgaw1dkjjMsQzNSpq41OevV3gWDsABfquzjKAEtGlCc3zWiKyJHJRnxKuY+Wlg+6BAtY7m8GX6IszBvH8yd8WV9eAXwNpmDDAwgbF61BusaAHeZVlE5OD5Wx9Qi2cJ0FtQDyPfvsnCN8oriFgRErKt2JgT3JJNNmWbLhkMQ/OsqWs93kcRF5BBF885veeQ9g0nmbf/FUPp1Tl1P++nAV1UbOmnO2aW+g2TP4wGRAaJdUfpsd5etmvYyDyz4TNVrpEx8AEnT5WTAP/fZ/Jh1SEzC9R5Zb/p+LaMlW2HxNUp/PCExCp8Wj0mTqPpFV/boGhnio5rEzmeN3m0OUTQ5SyWw7lGsCFgool36C7QgPDcqkEIJ0y4l1qgweF9IDfBlRYjXOfWJbSz6jpFOxzDXtQYLlZkEYCNTSmQnpnPtusVcvwt0GkleVA3LfiSF+NWwsce/RDQ4uFY0dZHdqZrx/XbccAF9+BCTuRxi+vGMl0ITI7/ALlknvWhuNF0U1v+XU4WOnOmJImwpClnfT5VgbxznPlhuCJtB4IQMKakSQUTB4+TSLaoXopki486ox2g1KMwQmSBOejVLs54tzcLyf6zgkQI0t+FNTTkjSzGPe7/xi ZDYro8C1 LMflU+47ZvulpMH2DqtLcM3YSGnHYQLDrJiRofrU1ao8/aw9B+dprqm958bZ17g33ANzWkzYkk9MN4P1lOaFCzdDfA5pY8HygRHp5dGvzKu6u+eNxjR/RP/4sIPyvvQwCESB0qDx1H1hnIulgC5SNj4Da5wlTxm0O7ynJPtk/yby8UAVl0bUXa0HAEazTBJKfRg7YVFsienHAvT0bSEioSOKnWLglczaOy9yzb2GLgzoSuukNiIB42SY3EjaVx+L0zUdC1yPcKYMXzVQgaTn6biXo+w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, 25 Feb 2024 at 17:03, Kent Overstreet wrote: > > We could satisfy the posix atomic writes rule by just having a properly > vectorized buffered write path, no need for the inode lock - it really > should just be extending writes that have to hit the inode lock, same as > O_DIRECT. > > (whenever people bring up range locks, I keep trying to tell them - we > already have that in the form of the folio lock, if you'd just use it > properly...) Sadly, that is *technically* not proper. IOW, I actually agree with you that the folio lock is sufficient, and several filesystems do too. BUT. Technically, the POSIX requirements are that the atomicity of writes are "all or nothing" being visible, and so ext4, for example, will have the whole write operation inside the inode_lock. Note that this is not some kind of locking requirement coming from some ext4 locking rule: it only does this for the buffered path, the DIO path happily says "if I'm not extending the size of the inode, I'll just take the lock for shared access". So this is literally only about buffered writes, and the atomicity within a folio is already dealt with with the folio lock (ext4 uses "generic_perform_write()" to do the actual writing part, which does *not* care about that lock). IOW, the whole inode lock is pointless for any real uses, but exists because _technically_ POSIX does not allow reads to see partial writes (ie if you see *one* page change, you have to see all of them change, so per-folio locking is not sufficient - you technically need to lock the whole operations against readers too, not just writers). Of course, in real life absolutely nobody cares, and you can see partial writes in many other ways, so this is really a completely "because of paper standards" serialization. Several other filesystems do *not* do that serialization, and as mentioned, the DIO paths also just said "hey, this isn't a normal write, so we'll ignore POSIX because technically we can". But to take a different example, ext2 just calls generic_file_write_iter() *without* taking the inode lock, and does locking one page at a time. As far as I know, nobody ever really complained. (It's not just ext2. It's all the old filesystems: anything that uses generic_file_write_iter() without doing inode_lock/unlock around it, which is actually most of them). And I find that silly locking rule a bit offensive, because it literally serializes accesses that shouldn't be serialized. IOW, it *should* be a "you do stupid things, you get what you deserve". Instead, it's a "everybody pays the price for giving stupid things a pointless semantic guarantee". Afaik, it has a purely historical reason for it - all the original UNIX read/write calls used a per-inode lock, so they were all serialized whether you liked it or not. Oh well. It's a pet peeve of mine. Linus