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 E31A8C77B78 for ; Wed, 26 Apr 2023 15:24:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7ED666B00F0; Wed, 26 Apr 2023 11:24:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 79D6A6B00F2; Wed, 26 Apr 2023 11:24:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63E1E6B00F3; Wed, 26 Apr 2023 11:24:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 54E7B6B00F0 for ; Wed, 26 Apr 2023 11:24:58 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 268584020C for ; Wed, 26 Apr 2023 15:24:58 +0000 (UTC) X-FDA: 80723915076.30.01D3DD2 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf19.hostedemail.com (Postfix) with ESMTP id EF32C1A0010 for ; Wed, 26 Apr 2023 15:24:55 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="Ep+byN//"; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682522696; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GPvsDH5jNOVR6Eyv2yuotNriNEuFABwoitK5mC3a5ek=; b=zhx81bBx5rFv6bDyz+KruwCGNX/TQOh8EIuTbU/08r+aF1Rr998YHgHM+z5lKNHAwOMV27 ZTOcYxsTZAKErc1ZktUtUQN6DfrLH6pW+4JbwU14JKGzUuEDyI20T57lav+ol/qQ4WykGe rJeiibqnOnSuQ8i2OTr0F6ebWvflzlw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="Ep+byN//"; spf=pass (imf19.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682522696; a=rsa-sha256; cv=none; b=cGfOPPayiMA1Z2uQLEWszPAhXPXeAiOwcoWMa45xiUBn7FFeh5rbRQENHTwmbo0abkDMrp x3gc7fAv/jrC66xFWGfNSGACOO+aH7PrpYQYDAGdDJu4ho/XRw21eBTKTnfz79uEEBm9JZ lRxR5M3O7XoZGJZV5UuSVIVT1Cq+TXM= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-9505214c47fso1357065366b.1 for ; Wed, 26 Apr 2023 08:24:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1682522694; x=1685114694; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=GPvsDH5jNOVR6Eyv2yuotNriNEuFABwoitK5mC3a5ek=; b=Ep+byN//ShUm0mEnGmNhxSFePnJp5vzi/a5Tbgi9cE9lQBsqLMsgePrOCr5nTLNIrp YBcbWvcF2e3Zf0LwQH9mG27s/jkD82N9kAWuTDHbxusogXZOODbKxbPKC9UaJQYOa+x/ MOMG6+B2CQe9elGCd/3sEkyhHrWtkDG77mvdI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682522694; x=1685114694; h=content-transfer-encoding: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=GPvsDH5jNOVR6Eyv2yuotNriNEuFABwoitK5mC3a5ek=; b=AysQkxS/pdBkSIOp1Sy/rBOGKr/bYBceMuuQjUR3s08qxOwOpXV27va9g5uvlNv2Go EBwHN5EpjrxUX+SVaARso39JRLH0RkxXpdWW3Hoe0FAH75qbtBVpkF3iidOGthrYDhN2 qXTyUAeXeyRKppvCYbjcocN9rwAEMQtQLbpkIJovGfaNzSuJHkotBNjAOE0exAYgY8Oa e+tW4YViwvm+jtIRZl8VN4VuiRqYGq+8xYZik1tex6c9bKciAcbw5FgumF/38sWBgPgk jThedvc4EqMmRnIJatRTBXQoV7r6P74WYo4Ov/FRPFjsUKdAc2/EWjBJh6cRa4QCT784 tJ7A== X-Gm-Message-State: AAQBX9dlFPqgnO0MOjDvtvzCSFhzATpDtLAbDJOkE84jkhVBQVfGMAjG PGtLkX5mMdz/UxXZ9npCzQIGrVHwNwovJJ7U7LU4Aw== X-Google-Smtp-Source: AKy350bbT+7mfMepJ2rQfMbKh1aLeD5kPhKw0uJqnDb8GmI069J6MBVI+tk7GOPM5n4MvjAy6/t4MQ== X-Received: by 2002:a17:906:830d:b0:94e:b3a1:3ed9 with SMTP id j13-20020a170906830d00b0094eb3a13ed9mr20718434ejx.49.1682522694119; Wed, 26 Apr 2023 08:24:54 -0700 (PDT) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id gn5-20020a1709070d0500b0094f29a53129sm8219632ejc.205.2023.04.26.08.24.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Apr 2023 08:24:53 -0700 (PDT) Received: by mail-ed1-f45.google.com with SMTP id 4fb4d7f45d1cf-50685f1b6e0so13335573a12.0 for ; Wed, 26 Apr 2023 08:24:53 -0700 (PDT) X-Received: by 2002:a05:6402:2c7:b0:502:61d8:233b with SMTP id b7-20020a05640202c700b0050261d8233bmr20090196edx.19.1682522693062; Wed, 26 Apr 2023 08:24:53 -0700 (PDT) MIME-Version: 1.0 References: <20230421221249.1616168-1-dianders@chromium.org> <20230421151135.v2.1.I2b71e11264c5c214bc59744b9e13e4c353bc5714@changeid> <20230422051858.1696-1-hdanton@sina.com> <20230425010917.1984-1-hdanton@sina.com> <20230426100918.ku32k6mqoogsnijn@techsingularity.net> In-Reply-To: <20230426100918.ku32k6mqoogsnijn@techsingularity.net> From: Linus Torvalds Date: Wed, 26 Apr 2023 08:24:36 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 1/4] mm/filemap: Add folio_lock_timeout() To: Mel Gorman Cc: Doug Anderson , Hillf Danton , Andrew Morton , Alexander Viro , Christian Brauner , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Yu Zhao , Matthew Wilcox Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: EF32C1A0010 X-Stat-Signature: m1hir5t3nt4t7ufw67zj8ydngadrw5j6 X-HE-Tag: 1682522695-549000 X-HE-Meta: U2FsdGVkX193Fvo34CShaD5ZTQerjFuAKjxTDXHAG9ojvv6eOfEMhGZj0107RineI7Nya7FnSjJHosLQsArVPkUH0YlNr9035OfwuQctFn+UFcU2AFxmZey/Xq9mOlefOo8pTlwqqvgNwq7iOLw0rDojqnONqwr5fr6S5kDsbHPAXTOu2Tej04abMCIF57VKYNcyz3mCFqP2CmGdlUHc+p+3tKb73/hlU3NHgQZCLeduQCyWit3GGRQrU+MScspufAnPCTVLlWpjthlufWNz+h9owbepOMIfzd7654n07vxLn0d9FZUwDNJ/p4wKYYKZTIIR178Zmr5OTL7+qaE8VrAEjbAech2zYoMMKNCAGydMaxhuAahJftBlDpVzBa3m88hWytjyMBXOX+wqW3vr5E7glmmzg8laOBlRAKH597Avwug7x+gB1XOtp5RhFkOwy4LqIruP8e/uJ5O2GgsmOAHiMyz6DguWdASjfrlF4S10wXpjvPDeQEBaVcpUAGlhB9Hny4D6LlaoqdrutkDGv4ufIn4CI4YE6A5DSnH7Ms/lcoOm/iCxRXk5vhqAVOzxJaOqiyvd+t/GXUqRDtvOMPzPfuYZZhM3zNzZgOfeWDV87s6RVMP9fw1dG9oWRVZbf5QUIOE73Ago0PArMlKhNlUtBj9K5znhYVv4JeDC0Q9V0QCP+RI4nr+mPIwfbpqcyJ277+ET//chxwGn27XTZRudiJVTtZJB86is1dLXuXcoKK+cPMgOTD55XRfHNIFI6R2ppshNYvBlOPN8DLldV+A7AZMpw/nFElcER1h2hgQC288UyOUYovG3xJNxH0VxODNdPKOVDI3tcoLs10ojm344B6YWKBl5CK6cmm0l0je22UL6LleqFIZFk/S2cu39U5JoTvfKawmM1YxLsk6VM86Dj16VPr/ajJM9yUtpv03Rx+rGP2WBQpUKQ6cfneTaNnb5sTsLjpzqCj+nraF Xdm3Jzl5 CKBEbTUGjl4mgP0hXiiYMdMv4ghAFPaFZ4w7iEEOcYSF9T+hhOeCdtcifBJFUOqcScIR80wZddmwqWE8mqPuMgBab5XLq6cY6+vE9zTPBWHCUMJs3hYQFM1JT23PwoNJaZsWfAWQddCFrlKCSr15xF2aIwpVdwtdzS7gYqONDtlSgKTL4E2f2oOOUnhegJM4cptLGQhsAggJCGaH6oM97fDBMzTH0HZ2uekvsAxYWjcuUiDlxWCJ2Z7qpmZLlRAgJVA7f8JGdK6K8WGJRf+7beQbCZKzMg++08zzO9wRK1sXs5JrPkI8gfT1m4eDCBPUqZH0p+Kpihp5kfsATjAikSHFcAP6Uxzg/QkhN/k1AO8U/gcBKxaYzjOgfz41Wow9bY+OfGao9jrXG+N8kCxv0fqFfqeTF/hfFk+uPSa1Feiv7frlqXDEkc4EdnUbyo8WNdBZP4yyLxPWEq1bsrpflwJ/51z4N9+72qtRT8eQGA8POayuuDjguxhxUeatWc6rldxi8/JqcvVTi658PEWr6hexQNvPVPUuV2dUaXrrPupP3ClhoMjB9+cK5THlZrlDhAsVL7o3lf7lX7Hlg7iHt6reRDsKvnLFsPsg0 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: On Wed, Apr 26, 2023 at 3:09=E2=80=AFAM Mel Gorman wrote: > > The reason I don't consider this patch a NAK candidate is that this is no= t > conditional locking as such because no special action is taken if the loc= k > cannot be acquired. If this comes from my rant against not having conditional locking for the O_NDELAY (well, the io_uring equivalent) IO path, then no, I don't think something like lock_page_timout() is "conditional locking". Some caller wanting to get the lock, but being willing to just go on and do something else after a timeout is fine. Within the context of something like memory compaction internally for the kernel that is fundamentally opportunistic anyway, that sounds fine to me. In fact, in contexts like that, even trylock is fine. We obviously have trylock in lots of places of the kernel. My "no conditional locking" is really that I do not think it's sane to have user IO fail with EAGAIN just because some data structure happened to be busy. It's a debugging nightmare with unlikely things that happen only in special conditions. Doing IO is not some "opportunistic" thing. We've actually had things like that before where people tried to make O_NDELAY mean "no locking" (I think that was driven at least partly by the old in-kernel web server patches), and it also causes actual problems with user space then busy-looping in a select() loop, because the select doesn't consider some low-level lock to be a waiting event. (The io_uring case is _slightly_ different from our historical issues in this area, in that the kernel can fall back to the user worker thread case, but it's all mixed up in that same IO path and that's why I absolutely hated that "if (X) trylock else proper_lock" approach). So a unconditional "lock with timeout" in the context of "we can just skip this if it times out" is perfectly fine by me. That said - the kcompactd code is not code I know, so maybe there are *other* issues with that patch, so this is also not an ACK from me. So please consider this just a "that is a very different case from the one I complained about". Linus