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 58B33C433EF for ; Thu, 20 Jan 2022 18:11:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92B536B009C; Thu, 20 Jan 2022 13:11:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DA416B009E; Thu, 20 Jan 2022 13:11:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77A966B00A0; Thu, 20 Jan 2022 13:11:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0218.hostedemail.com [216.40.44.218]) by kanga.kvack.org (Postfix) with ESMTP id 64F556B009C for ; Thu, 20 Jan 2022 13:11:10 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 208E496367 for ; Thu, 20 Jan 2022 18:11:10 +0000 (UTC) X-FDA: 79051457100.19.BE1B925 Received: from mail-pj1-f53.google.com (mail-pj1-f53.google.com [209.85.216.53]) by imf08.hostedemail.com (Postfix) with ESMTP id A6AAD160010 for ; Thu, 20 Jan 2022 18:11:09 +0000 (UTC) Received: by mail-pj1-f53.google.com with SMTP id d15-20020a17090a110f00b001b4e7d27474so6519467pja.2 for ; Thu, 20 Jan 2022 10:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gOcU0/BmRHJufgVqOwLZIOl2kit84wG17JB0ji+wG/E=; b=CXjw6VHLcXH9kggASFK9BPv3lhbEXdku5/He1K+ExRoI5XhJbAha1pWu3vN2jCZfj0 IFusV5YaZ3jKD/JSHQsyzj/ANjLsQ7ZVYUFpUrmD+u35VIK8vaCI2E0PYwTEDgpGfaok /tv0vSJvbOkVr/LaboT3SrxqaWWIi/UQ7iDWaWYJxUHuFdm58HnU56ADnNLuiQe+/k4U jGMqgWaw7GC+5vtl0zaWN1Okf5fy1EMW2uW0Cz3ltbSPfo6fYX81LT+m0Eatl7RIkvk/ jBMWJRs36igUM/wpf9j2ES3yZcSCJsLizrAoM9eIaYCPLfEWnXjcUphzNQdHIAWZTq1W vlfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gOcU0/BmRHJufgVqOwLZIOl2kit84wG17JB0ji+wG/E=; b=cOaUl1Vmo68gXK8MxM6zuoMPFvVRgxwPhE8+wv89kfQrCilAS029PXqUqC7/zFv8YC brEAjxh/CcOmtyWRf8UYf9GiXCvworLM4YMoxWlGcmjsVu+/lOhMPIdQtSwAFCo0yZxt lM7b3I1Wj9TsGSKfutm+lwJH9u1AwyMO3EKgqh2qQbcc8tnQLWlctG8nso2qkvYuINI0 fS7W0+0ij2gCekWZ0pffkZAL94VTJ4xmVQOZLXC3SIrnNbEyaQ6doaiRpeOKIhJWz8Cv +3xoGVRJgQ7MXFFXlrRWavuh5DtYpdjQOmF2UGANTkRlcw0w1uyL9pmDXryGYjRVgBO6 vmtw== X-Gm-Message-State: AOAM533buLj9p8Ig9Tjx0SIT0J4I9wFYpFQ1x++0tWGYHWBACHODo88/ ULTzGO9Aff14Rm9kg83mjFA= X-Google-Smtp-Source: ABdhPJxd5EtHygpRB84GizgP0wSPnE6KtTe40W37fhj4/78BDcGz25kp4Qs6sK/1IyfnbvzWdBcXww== X-Received: by 2002:a17:902:8b8b:b0:149:6d32:4b4c with SMTP id ay11-20020a1709028b8b00b001496d324b4cmr39794880plb.8.1642702268453; Thu, 20 Jan 2022 10:11:08 -0800 (PST) Received: from smtpclient.apple ([66.170.99.2]) by smtp.gmail.com with ESMTPSA id kx11sm2496449pjb.1.2022.01.20.10.11.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jan 2022 10:11:07 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) Subject: Re: [PATCH] mm: reuse the unshared swapcache page in do_wp_page From: Nadav Amit In-Reply-To: <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com> Date: Thu, 20 Jan 2022 10:11:06 -0800 Cc: "zhangliang (AG)" , Andrew Morton , Linux-MM , Linux Kernel Mailing List , wangzhigang17@huawei.com, Matthew Wilcox , Linus Torvalds Content-Transfer-Encoding: quoted-printable Message-Id: <6225EAFF-B323-4DC5-AC4C-885B29ED7261@gmail.com> References: <20220113140318.11117-1-zhangliang5@huawei.com> <172ccfbb-7e24-db21-7d84-8c8d8c3805fd@redhat.com> <9cd7eee2-91fd-ddb8-e47d-e8585e5baa05@redhat.com> <747ff31c-6c9e-df6c-f14d-c43aa1c77b4a@redhat.com> <8931808d-db61-0f06-ceb3-f48a83b1f74c@redhat.com> To: David Hildenbrand X-Mailer: Apple Mail (2.3693.40.0.1.81) X-Rspamd-Queue-Id: A6AAD160010 X-Stat-Signature: fm7ephicnc8phfqc7nh75dbsn1taxztf Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=CXjw6VHL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.53 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-Rspamd-Server: rspam08 X-HE-Tag: 1642702269-616500 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 Jan 20, 2022, at 10:00 AM, David Hildenbrand = wrote: >=20 > On 20.01.22 18:48, Nadav Amit wrote: >>=20 >>> On Jan 20, 2022, at 6:15 AM, David Hildenbrand = wrote: >>>=20 >>> On 17.01.22 14:31, zhangliang (AG) wrote: >>>> Sure, I will do that :) >>>=20 >>> I'm polishing up / testing the patches and might send something out = for discussion shortly. >>> Just a note that on my branch was a version with a wrong condition = that should have been fixed now. >>>=20 >>=20 >> Sorry for being late for the discussion. >>=20 >> David, does any of it regards the lru_cache_add() reference issue = that I >> mentioned? [1] >=20 > No, unfortunately not in that part of my work. *Maybe* we could also = try > to handle that reference similarly to the swapcache, but the question = is > if we can't wait for PageAnonExclusive. >=20 > Right now I have the following in mind to get most parts working as > exptected: >=20 > 1. Optimize reuse logic for the swapcache as it seems to be easy > 2. Streamline COW logic and remove reuse_swap_page() -- fix the CVE = for > THP. > 3. Introduce PageAnonExclusive and allow FOLL_PIN only on > PageAnonExclusive pages. > 4. Convert O_DIRECT to FOLL_PIN >=20 > We will never ever have to copy a page PageAnonExclusive page in the = COW > handler and can immediately reuse it without even locking the page. = The > existing reuse logic is essentially then used to reset = PageAnonExclusive > on a page (thus it makes sense to work on it) where the flag is not = set > anymore -- or on a fresh page if we have to copy. >=20 > That implies that all these additional references won't care if your = app > doesn't fork() or KSM isn't active. Consequently, anything that > read-protects anonymous pages will work as expected and should be as > fast as it gets. >=20 > Sounds good? At least to me. If only swap/migration entries wouldn't = be > harder to handle than I'd wish, that's why it's taking a little and = will > take a little longer. Thanks for the quick response. I would have to see the logic to = set/clear PageAnonExclusive to fully understand how things are handled. BTW, I just saw this patch form PeterZ [1] that seems to be related, as it deals with changing protection on pinned pages. [1] = https://lore.kernel.org/linux-mm/20220120160822.666778608@infradead.org/=