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 3A063C433FE for ; Mon, 7 Nov 2022 20:35:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BC4456B0071; Mon, 7 Nov 2022 15:35:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B74AF8E0002; Mon, 7 Nov 2022 15:35:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A63F78E0001; Mon, 7 Nov 2022 15:35:49 -0500 (EST) 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 941516B0071 for ; Mon, 7 Nov 2022 15:35:49 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 6B2E340D78 for ; Mon, 7 Nov 2022 20:35:49 +0000 (UTC) X-FDA: 80107802418.08.2610CE5 Received: from mail-qv1-f52.google.com (mail-qv1-f52.google.com [209.85.219.52]) by imf28.hostedemail.com (Postfix) with ESMTP id C95EEC0010 for ; Mon, 7 Nov 2022 20:35:48 +0000 (UTC) Received: by mail-qv1-f52.google.com with SMTP id lf15so8498524qvb.9 for ; Mon, 07 Nov 2022 12:35:48 -0800 (PST) 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=rmekPIfsDhO/c1VKUUGZV/Wt7GFULF9qq4iGNhwtPaQ=; b=WoUgENFw6x+yDkOL6DTJqhHSKthAbh8p3B4djaVfiu1Y1OuAAH5VN0vqEy2WlUru6T qBEWcImUuA95okNKVQS17+EvIUay4jWOzyHexqa6/e0Q/rmKyMAQKq5oz9xW/cpg+3BR IBAgXFUqMgzbuGwbQH9Ng0QPbzKb63u+5xeN8= 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=rmekPIfsDhO/c1VKUUGZV/Wt7GFULF9qq4iGNhwtPaQ=; b=mJZvlM6ihvhe/Rb8vdZ4YULk2akH4cbnsfEN13IskltJPumXGbCLcK4JEO8xtBIgut jTJAtMgDNnzkXDq5Z8rFJMzGxt/o+jYEJ+047McWB/1KmkoldB6B/WJ3rriwdsUcc6CQ QQt9Def9/LGDiohnCNZ7JZE3fL6eG/krmlWlMGKplUv3LnqXwyJF3tEOyi/ZI98aVzHl pXqtpIj3sGQAsyNMlz1KMtW99BwS+kab/Ck9VI1u5C1DLvARhmf9AiBKvEhUZtnUcs3g pK7rRFnrv7ZOKVjR4TJ1hjwML1YIP1OWcPEf/eJ5pDaD24snt4erGexUHJNtPgCx8P+R XqQg== X-Gm-Message-State: ACrzQf3J/mgV+Bx+k5WBuFU5lE3iAyq/bD7ghGnei2ZXNCTt1yvj+IxH aomz+cnucLCULxp4vg8y1tJAsg62k7Hxqg== X-Google-Smtp-Source: AMsMyM7IzYoCug46y/fOv6TqvJErCIgmw0wiPmuDKMtC93CfGUMfheoyYQivTtP3341v7Th+cIi9Tg== X-Received: by 2002:a0c:b3da:0:b0:4b4:a3d6:fa27 with SMTP id b26-20020a0cb3da000000b004b4a3d6fa27mr46186660qvf.14.1667853347819; Mon, 07 Nov 2022 12:35:47 -0800 (PST) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id c24-20020a05620a269800b006e2d087fd63sm7612533qkp.63.2022.11.07.12.35.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Nov 2022 12:35:47 -0800 (PST) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-333a4a5d495so115672977b3.10 for ; Mon, 07 Nov 2022 12:35:46 -0800 (PST) X-Received: by 2002:a25:bd7:0:b0:6d7:7464:4859 with SMTP id 206-20020a250bd7000000b006d774644859mr5895133ybl.362.1667852967798; Mon, 07 Nov 2022 12:29:27 -0800 (PST) MIME-Version: 1.0 References: <8a1e97c9-bd5-7473-6da8-2aa75198fbe8@google.com> In-Reply-To: From: Linus Torvalds Date: Mon, 7 Nov 2022 12:29:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mm: delay rmap removal until after TLB flush To: Johannes Weiner Cc: Hugh Dickins , Stephen Rothwell , Alexander Gordeev , Peter Zijlstra , Will Deacon , Aneesh Kumar , Nick Piggin , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , Sven Schnelle , Nadav Amit , Jann Horn , John Hubbard , X86 ML , Matthew Wilcox , Andrew Morton , kernel list , Linux-MM , Andrea Arcangeli , "Kirill A . Shutemov" , Joerg Roedel , Uros Bizjak , Alistair Popple , linux-arch Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667853348; a=rsa-sha256; cv=none; b=OLp6uW+JoBrtOaaTsKHOIMF9hD2N1FHbkHpPyprK1gCzMvPqfjR35XMaGvcdqMDf7Sh3CN VB3AJcts8qxr3EXA9PI9MAALFD7DaEO0oMv4zPWsSlkvHho28zCqbcP5co8eCaCMIyMN3p aPf5Mxe1d2YzVIgPRrvG6grCwCqWRNQ= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WoUgENFw; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.52 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=1667853348; 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=rmekPIfsDhO/c1VKUUGZV/Wt7GFULF9qq4iGNhwtPaQ=; b=WeFfy7dYaJM1rvUkdnZURrFx6qcoTYKAwscZxQoQGkCy5rpNnBE86T6g5zx6542dUWe/ZC WLnBRESDPQOYBGBUqrtDNcw8srnI2eCsO2YlFebQflbkwD+UGYmh5ebE8ZHrTUVf9tWEIl tbNFvC7AulLm2opAaCoUwqz782lWPk8= X-Stat-Signature: eihfi6yr9576a4udyqipgbneuqsjn4o6 X-Rspamd-Queue-Id: C95EEC0010 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=WoUgENFw; spf=pass (imf28.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.52 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1667853348-212290 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 Mon, Nov 7, 2022 at 12:07 PM Johannes Weiner wrote: > > - If we DO want to codify the pte lock requirement, we should just > remove the lock_page_memcg() altogether, as it's fully redundant. > > I'm leaning toward that second option. The thing is, that's very much the case we do *not* want. We need to delay the rmap removal until at least after the TLB flush. At least for dirty filemapped pages - because the page cleaning needs to see that they exists as mapped entities until all CPU's have *actually* dropped them. Now, we do the TLB flush still under the page table lock, so we could still then do the rmap removal before dropping the lock. But it would be much cleaner from the TLB flushing standpoint to delay it until the page freeing, which ends up being delayed until after the lock is dropped. That said, if always doing the rmap removal under the page table lock means that that memcg lock can just be deleted in that whole path, I will certainly bow to _that_ simplification instead, and just handle the dirty pages after the TLB flush but before the page table drop. Linus