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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 98F13FA3741 for ; Mon, 31 Oct 2022 15:43:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231946AbiJaPnq (ORCPT ); Mon, 31 Oct 2022 11:43:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229787AbiJaPnn (ORCPT ); Mon, 31 Oct 2022 11:43:43 -0400 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4F3110FED for ; Mon, 31 Oct 2022 08:43:42 -0700 (PDT) Received: by mail-pf1-x430.google.com with SMTP id y13so11003755pfp.7 for ; Mon, 31 Oct 2022 08:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5tUXpWC1H7P0Jns6tHF58gKyo4qTrk4UrpN1+5tdF18=; b=cv1mx2nJdWzm9o2OtXlRHPxnB0CspofcOk6YtVCzD1O8YQxZk2Eil3lQyAj0B3zY6D PZ+8w4oCpZMIRfyKiPSJVqeTc5BTuOxPzKEuoCwbXemkHBhXU5d4Ootfw0RvPBak9Bel BDW6NUcC6nJc0CQhbr+u2WfVGqo2h/ttJlkCnQO3gkuY/GWnZrtwCBhe5fLnbqyujT+t awU1AlLcu00lfXZNRWTw1A0G4VwrmzTE0zvOSCjNRMqMnxJvFIMy3SudGy3gNLiKX0bv YJX82S079L2yXFtKNpwgg8w8HNcq9Vg0sTBHWuE3BQhYJ0EqpTNWx5fiDNY2BSiIrKoQ 0uQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5tUXpWC1H7P0Jns6tHF58gKyo4qTrk4UrpN1+5tdF18=; b=LeMoUvRQTvvBfx4P3VDXm8wwjjK0NkWPj3txn1KbUEYBrpHzhRdWQlXFKPUTc2oJVR vel6z8K6n8khJfjobJ/pt2eAGE1CuVvIKIfJjhO9eolASLUZhehAdxqxts9oOb2TxibW lRMNmWk9w3O9LvYODKRLWYx5jiZanDFKGeAri53TMt5HioXVRghRZcgeYxASMF7w6aGg dN9CQqk/F5D+l1aKIzxHAnlgqOCzYW4zOGBJ4AH5R53JDAQx3F9vP/au7xD0jwRetUHw Uwf4Q3ue8VmzcIauTYFv6PP1fSA0ugpsf+RHGc+e5vlWPrBGJgS9KLaC3VA1LMNUP4zI Lvbg== X-Gm-Message-State: ACrzQf18mNIFYw7FEH3zhInJRxFt90GlqNK7jt1uZDldLzMeJbBBT2oi ThNCgY1o3AgU+mYArOYS4jPG7ApesvW1TRXBPw8= X-Google-Smtp-Source: AMsMyM7LqDY9bi2DWvg4h01dPwTkDsm6fOPR3gR58jN/HTZlEu2YwniA3Zv19zGfcT2E8eNdOOqTqQ== X-Received: by 2002:a63:e511:0:b0:46f:98cf:13d3 with SMTP id r17-20020a63e511000000b0046f98cf13d3mr9385789pgh.363.1667231021972; Mon, 31 Oct 2022 08:43:41 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id 4-20020a621404000000b0056c704abca7sm4754063pfu.220.2022.10.31.08.43.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Oct 2022 08:43:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment From: Nadav Amit In-Reply-To: Date: Mon, 31 Oct 2022 08:43:37 -0700 Cc: Peter Zijlstra , Jann Horn , John Hubbard , X86 ML , Matthew Wilcox , Andrew Morton , kernel list , Linux-MM , Andrea Arcangeli , "Kirill A . Shutemov" , jroedel@suse.de, ubizjak@gmail.com, Alistair Popple Content-Transfer-Encoding: quoted-printable Message-Id: <0E3DDDE4-FD20-40ED-A418-222AAA546596@gmail.com> References: <20221022111403.531902164@infradead.org> <20221022114424.515572025@infradead.org> <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com> <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> <47678198-C502-47E1-B7C8-8A12352CDA95@gmail.com> <140B437E-B994-45B7-8DAC-E9B66885BEEF@gmail.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3696.120.41.1.1) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Oct 30, 2022, at 10:00 PM, Linus Torvalds = wrote: > So the current ordering rules are basically that we need to do > set_page_dirty() *and* we need to flush the TLB's before dropping the > page table lock. That's what gets us serialized with "mkclean=E2=80=9D. I understand. I am still not sure whether ordering the set_page_dirty() = and dropping the mapcount reference cannot suffice for the reclaim logic not = to free the buffers if the page is dirtied. According to the code, shrink_page_list() first checks for = folio_mapped() and then for folio_test_dirty() to check whether pageout() is necessary. IIUC, the buffers are not dropped up to this point and set_page_dirty() would always set the page-struct dirty bit. IOW: In shrink_page_list(), when we decide on whether to pageout(), we should see whether the page is dirty (give or take smp_rmb()). But this is an optimization and I do not know all the cases in which = buffers might be dropped. My intuition says that they cannot be dropped while mapcount !=3D 0, but I need to further explore it.