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 1E42BC38A02 for ; Sun, 30 Oct 2022 18:52:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9AA006B0071; Sun, 30 Oct 2022 14:52:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 95ADC6B0073; Sun, 30 Oct 2022 14:52:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 821EE6B0074; Sun, 30 Oct 2022 14:52:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7323E6B0071 for ; Sun, 30 Oct 2022 14:52:08 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 49F1B1C5DDA for ; Sun, 30 Oct 2022 18:52:08 +0000 (UTC) X-FDA: 80078510736.17.E376792 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) by imf09.hostedemail.com (Postfix) with ESMTP id C6FCB140009 for ; Sun, 30 Oct 2022 18:52:07 +0000 (UTC) Received: by mail-qk1-f179.google.com with SMTP id s20so77476qkg.5 for ; Sun, 30 Oct 2022 11:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sGJoZ3wR3C11xvb7GaIg6baorbhSsKxe2IOKOLyB7c0=; b=eCoZ3hMHphyp8KZRGL74Bxq12EtKF7LycFxetVP38YeAh77jx8lE0W6TIpMSyXgkw3 gk95GDzPoo4LNTdqUIaNHzANbkU32txnpbsaYOlLYpC01QCNI/o9G8a2/513H6cNImg5 wplL7HkmDP3UbHq9YI3ASdy3oSUO6in9YjJJ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=sGJoZ3wR3C11xvb7GaIg6baorbhSsKxe2IOKOLyB7c0=; b=nuA6bNQanh0e7H/pL/2nDzqmKsCwd52wfveB7JoAVPPC6iIi3u2u09fglWzsSF+C5F 1qXqkgOIIVClZkYk1/2Nb+u4kRnStSUp9HvLN6kz8PZ3ZQ5njVnjUgmOV4hR78t96ytI Ya+o2mZC+UefbgSt3AZ8UljtO/WAfzlfwPx36Apkx97viUSndk/hoRVQ/oQJepEeAOAI lM3wozAiyicg+kxFmgicKpu3sZdzOmxVAhp6BniAZpTJd+cGplwFj/a5c5iGwHbR1DFr eZa/JdF+A370cr+CJ9ow9fPY49MuNsVUyJU29rhKptGaA8iEn+yW3NSn9IGVGO5eUgwb hw+Q== X-Gm-Message-State: ACrzQf19KoUiuM5R62pU4GMF+YJQgw3StIxL1zkr5OkutwsCx21KQ4aa IBNK401ZDo+k4fs/YU2Dmz8Veca8pSbDbg== X-Google-Smtp-Source: AMsMyM7uJyMwZAbuUvcA8BysoW6CSqaChDz5kSf8LC9mKh84RkvWgRcUirZj/hl6fW/Oxt8bOMNWCg== X-Received: by 2002:ae9:e116:0:b0:6fa:30fc:182f with SMTP id g22-20020ae9e116000000b006fa30fc182fmr119888qkm.401.1667155926676; Sun, 30 Oct 2022 11:52:06 -0700 (PDT) Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com. [209.85.128.180]) by smtp.gmail.com with ESMTPSA id w20-20020a05620a445400b006eeae49537bsm3296100qkp.98.2022.10.30.11.52.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 30 Oct 2022 11:52:05 -0700 (PDT) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-36a4b86a0abso91063257b3.7 for ; Sun, 30 Oct 2022 11:52:04 -0700 (PDT) X-Received: by 2002:a81:555:0:b0:36b:2d71:5861 with SMTP id 82-20020a810555000000b0036b2d715861mr9438354ywf.340.1667155924532; Sun, 30 Oct 2022 11:52:04 -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> In-Reply-To: From: Linus Torvalds Date: Sun, 30 Oct 2022 11:51:48 -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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667155927; 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=sGJoZ3wR3C11xvb7GaIg6baorbhSsKxe2IOKOLyB7c0=; b=Z0nyEEvjaTaRlZuiE3Mct5b1ikFcTQBzsdKz2nrKxZtNfjtvtFHgk9TMKIwNl+a8W230k1 iEzAev0mKIrC5Vun4d1EHFm+QHmpFM0dv8HNX6HhP15wx8tW81dBRDPclkyWn4cNjeI+cU OE4m8mDlQ23vUzvwZIxyiYp2ALCg4BU= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=eCoZ3hMH; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667155927; a=rsa-sha256; cv=none; b=S+h0HKnETtjmbe7IYyoiTcjjPQtrKnMfrcQI0n7QEM/rHJHYPELE0gJ3qQ5kr60FO/ozxv ydaefKhk5ry/s3Ysi61QT31EhEN/5HWKCL8eO43mNPVc0wDUOXzLcwvlApv2JjcDgi9qeH UV4HsJGEtSGAHxoFiVtfG5VHveiM60g= Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=eCoZ3hMH; spf=pass (imf09.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Queue-Id: C6FCB140009 X-Rspamd-Server: rspam03 X-Stat-Signature: yejcsmubsnjiy6mg3scbewzdsc1595kw X-HE-Tag: 1667155927-303949 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 Sun, Oct 30, 2022 at 11:19 AM Linus Torvalds wrote: > > And we'd _like_ to do the TLB flush before the remove_rmap(), but we > *really* don't want to do that for every page. Hmm. I have yet another crazy idea. We could keep the current placement of the TLB flush, to just before we drop the page table lock. And we could do all the things we do in 'page_remove_rmap()' right now *except* for the mapcount stuff. And only move the mapcount code to the page freeing stage. Because all the rmap() walk synchronization really needs is that 'page->_mapcount' is still elevated, and if it is it will serialize with the page table lock. And it turns out that 'page_remove_rmap()' already treats the case we care about differently, and all it does is lock_page_memcg(page); if (!PageAnon(page)) { page_remove_file_rmap(page, compound); goto out; } ... out: unlock_page_memcg(page); munlock_vma_page(page, vma, compound); for that case. And that 'page_remove_file_rmap()' is literally the code that modifies the _mapcount. Annoyingly, this is all complicated by that 'compound' argument, but that's always false in that zap_page_range() case. So what we *could* do, is make a new version of page_remove_rmap(), which is specialized for this case: no 'compound' argument (always false), and doesn't call 'page_remove_file_rmap()', because we'll do that for the !PageAnon(page) case later after the TLB flush. That would keep the existing TLB flush logic, keep the existing 'mark page dirty' and would just make sure that 'folio_mkclean()' ends up being serialized with the TLB flush simply because it will take the page table lock because we delay the '._mapcount' update until afterwards. Annoyingly, the organization of 'page_remove_rmap()' is a bit ugly, and we have several other callers that want the existing logic, so while the above sounds conceptually simple, I think the patch would be a bit messy. Linus