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 9D9AEFA3741 for ; Mon, 31 Oct 2022 17:33:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229695AbiJaRdO (ORCPT ); Mon, 31 Oct 2022 13:33:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36180 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229495AbiJaRdL (ORCPT ); Mon, 31 Oct 2022 13:33:11 -0400 Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FD6611179 for ; Mon, 31 Oct 2022 10:33:11 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id o8so8779849qvw.5 for ; Mon, 31 Oct 2022 10:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; 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=wO1aXGez9nOhy2a+Zn5RD+RAHyQUNPFJqnfXakKdh28=; b=f5ptxWlLLcXdghefXYE0GvwEBlSe2liMn3DrOmZMCY7LFSlAbtO0iLErEaZVfejg/Y Kx/GBuhsRS3JG5bobpj9w6WcYfAH9TsouB6zoEn9T6kaOeTfZxIHJB9lag9lVgkmsAN2 M/FvOPQtTrbDWHeQVYWxfpFrLN57Pme71gDxo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=wO1aXGez9nOhy2a+Zn5RD+RAHyQUNPFJqnfXakKdh28=; b=7dqFzjddaenf8N2T0EWbbtpZ/7EDwAE+c3MN3tH/r6JSNj8WDxStuBSYUYpdA4cKJZ 4GHGNaRZsZSgC0oQ7j2CQOBSZ9Seh1OZlzQwSzgl1cex+3ChwjEwQSFNH8ySCfJ8PAZL IM4dZDtthe9/eT+a0j8vxGFSJbkqmsFEmwnehNBF1kbjPvvFoNUsbsK7oh7EY2h9ZzMK wFV3mBgVutLzhOZPPSOyEt4kSTINUReloh5ycj4wlsWpiaSd+zMPNtTaSLY6Vd9R2C5d 31PYXRe1mCUkMbVLHgy/h2aGbXugrk1HU+QR9chwU3SgIWMNhWycaukzmjV9/vORnO8g 6cAw== X-Gm-Message-State: ACrzQf1Cw0lLcUoW9XM4VxdkdnarRyedZd8UWbTZCdmE8wJMlhZLLpKy mL9mm6dIxf9CFjCXg7j1gRGDgtGRdiq+xg== X-Google-Smtp-Source: AMsMyM6N7PBbCY7teQy/ElTbFYdKvlxm7BhnTh02+8XqXUYF4iANrx19NaygW834eWkBFaV2Se0Pig== X-Received: by 2002:a05:6214:2689:b0:4b7:235b:b607 with SMTP id gm9-20020a056214268900b004b7235bb607mr12127421qvb.108.1667237590087; Mon, 31 Oct 2022 10:33:10 -0700 (PDT) Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id s10-20020a05620a29ca00b006f1187ca494sm4683845qkp.28.2022.10.31.10.33.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Oct 2022 10:33:09 -0700 (PDT) Received: by mail-yb1-f180.google.com with SMTP id f205so14544417yba.2 for ; Mon, 31 Oct 2022 10:33:09 -0700 (PDT) X-Received: by 2002:a05:6902:124f:b0:66e:e3da:487e with SMTP id t15-20020a056902124f00b0066ee3da487emr14959950ybu.310.1667237588682; Mon, 31 Oct 2022 10:33:08 -0700 (PDT) MIME-Version: 1.0 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> <0E3DDDE4-FD20-40ED-A418-222AAA546596@gmail.com> In-Reply-To: <0E3DDDE4-FD20-40ED-A418-222AAA546596@gmail.com> From: Linus Torvalds Date: Mon, 31 Oct 2022 10:32:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment To: Nadav Amit 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-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 31, 2022 at 8:43 AM Nadav Amit wrote: > > 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() a= nd > dropping the mapcount reference cannot suffice for the reclaim logic not = to > free the buffers if the page is dirtied. Ahh, ok. > 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 buff= ers > might be dropped. My intuition says that they cannot be dropped while > mapcount !=3D 0, but I need to further explore it. Yes, the above sounds like one fairly good way out of the whole forced TLB flushing for dirty pages, while still keeping the filesystem code happy. But at this point it's an independent issue. And I really would like any fix like that to also fix the whole issue with GUP too, which seems related. Linus