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 AD804C433FE for ; Thu, 3 Nov 2022 17:09:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BA8E6B0072; Thu, 3 Nov 2022 13:09:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 043F56B0073; Thu, 3 Nov 2022 13:09:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E01486B0074; Thu, 3 Nov 2022 13:09:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CDFA66B0072 for ; Thu, 3 Nov 2022 13:09:32 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 569BEABCF1 for ; Thu, 3 Nov 2022 17:09:32 +0000 (UTC) X-FDA: 80092767384.07.E40ACF4 Received: from mail-qv1-f49.google.com (mail-qv1-f49.google.com [209.85.219.49]) by imf04.hostedemail.com (Postfix) with ESMTP id CF9E240008 for ; Thu, 3 Nov 2022 17:09:31 +0000 (UTC) Received: by mail-qv1-f49.google.com with SMTP id h10so1556934qvq.7 for ; Thu, 03 Nov 2022 10:09:31 -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=JxCfvbb+eoelACSav5gOVJGA8b7JZzX3u9t6lpOqhGc=; b=c21oKw15OEDs7jPQQCx5/Q6jAakEjh4QCyHrqDrHmt1tZB5JiHbbDJmM+26GNCOUuA n2GMHrJ6v80we2vb5tM+7RBrSn/OgbLvIvKDSypwoGrv+vFeYz+qEx5tgHNFD4SDuMUn DyCZcKZmr8k62mDFGein3IhVz7jo4hs0ekZoI= 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=JxCfvbb+eoelACSav5gOVJGA8b7JZzX3u9t6lpOqhGc=; b=GSk25fUX7BdyizcoF5YEzu8ow1khQSiYL8TSPfRMQgObk5o6c+2CVZWxwBZIUGewLV KKtQZhbgoNfeh5rttE6AiFeIcv2ULJMBwVbdFtJR9/R/CDBhXo8/JSBCrrJAGEKDKf3j MRKSMgqnDwOx01QUdpv0W6Yt21NzqHRSUo0V+x6tbVGGmqetFcMOnfG8MFV3W7xC0Bnp fvo7RoQoB/henmKQMcXzN8hn0HGMTefeUGBB2YYzllxBNw5HGozNXvYoG14acf4+vwWT 77rA2LJl8dQsEZJyMDt+D/sY8bGeC0RGmFqscoT9jD7WSaSTESKAElEuSj5BpoCL3qNY P3YA== X-Gm-Message-State: ACrzQf1Ys0T3WCRDvH/0Llc1gEoqotrR0FhtMgM24wpI4d/52dSotThd X3gMLGojwsaN2LkxTe6HFwLix5+RJRuOGA== X-Google-Smtp-Source: AMsMyM4gX1c5vyGPW35wW7MxOT4JowUwdiQVnyp801v5SIWIYYFlMx5kS3w7jEUvhNQsCZsbrfPUmw== X-Received: by 2002:a05:6214:76d:b0:4bb:e59a:17dc with SMTP id f13-20020a056214076d00b004bbe59a17dcmr23257381qvz.125.1667495370782; Thu, 03 Nov 2022 10:09:30 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id j2-20020a05620a410200b006fa4cefccd6sm1181374qko.13.2022.11.03.10.09.27 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Nov 2022 10:09:27 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id o70so2997405yba.7 for ; Thu, 03 Nov 2022 10:09:27 -0700 (PDT) X-Received: by 2002:a25:5389:0:b0:6bc:f12c:5d36 with SMTP id h131-20020a255389000000b006bcf12c5d36mr29702771ybb.184.1667495367212; Thu, 03 Nov 2022 10:09:27 -0700 (PDT) MIME-Version: 1.0 References: <47678198-C502-47E1-B7C8-8A12352CDA95@gmail.com> <140B437E-B994-45B7-8DAC-E9B66885BEEF@gmail.com> <4f6d8fb5-6be5-a7a8-de8e-644da66b5a3d@redhat.com> In-Reply-To: From: Linus Torvalds Date: Thu, 3 Nov 2022 10:09:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: mm: delay rmap removal until after TLB flush To: David Hildenbrand Cc: Peter Zijlstra , Will Deacon , Aneesh Kumar , Nick Piggin , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , 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=1667495371; a=rsa-sha256; cv=none; b=yPR/IZ+f/OLNTd2ypqRhZCBQ9jezK5P4rbz/ysbg9x5+KURLG6hS03n73ix/9PSchIUCJ1 a7VNncGY4ufWvKqASu1lZAf2Gz7GmB9o7rsYMUYeVNPcWsq9ukVNYYW1hAOdB8HT/BidR0 UAWn1jEtxZS9jpwNzPIa3EZApb9wRvc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=c21oKw15; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667495371; 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=JxCfvbb+eoelACSav5gOVJGA8b7JZzX3u9t6lpOqhGc=; b=odncLI+4bynEfYEwfwi1xmiN8CzsBUPWur4MmPRgD6LZGCIj8PCCb6GbLJ3nH+E3BeIEH9 WapwPhng6h22wVCLzJySNYBMQicfZD/j4WpB1ceDzo3CycJzgxz1SUmhCN2uyEe/nMVZFV 4jzr/p+2DHvjvNlZo2WF/19Gqp00VxA= X-Rspamd-Server: rspam02 X-Rspam-User: Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=c21oKw15; dmarc=none; spf=pass (imf04.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Stat-Signature: pcxg8iwjc1e1xrxz6q1ehj8fzi4tor4q X-Rspamd-Queue-Id: CF9E240008 X-HE-Tag: 1667495371-39353 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 Thu, Nov 3, 2022 at 9:54 AM Linus Torvalds wrote: > > But again, those changes would have made the patch bigger, which I > didn't want at this point (and 'release_pages()' would need that > clean-in-place anyway, unless we changed *that* too and made the whole > page encoding be something widely available). And just to clarify: this is not just me trying to expand the reach of my patch. I'd suggest people look at mlock_pagevec(), and realize that LRU_PAGE and NEW_PAGE are both *exactly* the same kind of "encoded_page" bits that TLB_ZAP_RMAP is. Except the mlock code does *not* show that in the type system, and instead just passes a "struct page **" array around in pvec->pages, and then you'd just better know that "oh, it's not *really* just a page pointer". So I really think that the "array of encoded page pointers" thing is a generic notion that we *already* have. It's just that we've done it disgustingly in the past, and I didn't want to do that disgusting thing again. So I would hope that the nasty things that the mlock code would some day use the same page pointer encoding logic to actually make the whole "this is not a page pointer that you can use directly, it has low bits set for flags" very explicit. I am *not* sure if then the actual encoded bits would be unified. Probably not - you might have very different and distinct uses of the encode_page() thing where the bits mean different things in different contexts. Anyway, this is me just explaining the thinking behind it all. The page bit encoding is a very generic thing (well, "very generic" in this case means "has at least one other independent user"), explaining the very generic naming. But at the same time, the particular _patch_ was meant to be very targeted. So slightly schizophrenic name choices as a result. Linus