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 F1380ECAAA1 for ; Thu, 27 Oct 2022 20:31:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 42C706B0071; Thu, 27 Oct 2022 16:31:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DCE66B0073; Thu, 27 Oct 2022 16:31:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 27D686B0074; Thu, 27 Oct 2022 16:31:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 160966B0071 for ; Thu, 27 Oct 2022 16:31:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D569FC0D47 for ; Thu, 27 Oct 2022 20:31:41 +0000 (UTC) X-FDA: 80067875202.01.0E70EC1 Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by imf02.hostedemail.com (Postfix) with ESMTP id 6AACD8003F for ; Thu, 27 Oct 2022 20:31:41 +0000 (UTC) Received: by mail-qk1-f180.google.com with SMTP id a5so2004745qkl.6 for ; Thu, 27 Oct 2022 13:31:41 -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=40/NzUhqBfpBB930IrYklEEa68Z0CgmOyOOoo4pZLBo=; b=f3ObglpSHvlAmkyYbSNMXkn3I28foU8FiO9qbDYRaBj2NoxEHo/iigszE2yQs0TSKW Evu731JN6+9voVpQZrxahvnki+UtO9PruUqprG4YisNFTi9d2MFS5AWdI4374Pg51fP3 ABAe6o3LkroGX/O2nx+pllOZLvY2b8mEFq11g= 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=40/NzUhqBfpBB930IrYklEEa68Z0CgmOyOOoo4pZLBo=; b=2YZ4mW8T+YARYNBYvE/pHZDrjlUHKJUcExWTxpYR0ZIWEfEobXCv3HJVwf8mUaZJ9J aTt0MDLfLEY2KjtfTqcTN1S7OFio9f+hQnz6EMArflMC0/I2Bj/OEZ3QA2BUqc41+IAQ bb2ZDANkTVCZuJorFcskGJoR6WWWcnZTwvsZXXruMuhhJmP8b2Q/fnoCl8eoaKfe09oN o5e4D6DNLRa7orw4i3FEtXrpupWPfmVXsl6MPH3uT7mnUkbJJsjuVGi2bOlOrS5y/Zbj VfdfHjZbTAJaKI4eCmpSD+Z/HxflJ1LJsfBSreK4MUnwpBr4A7lUjNIeDtj6lPZRf3F4 JvYQ== X-Gm-Message-State: ACrzQf0Jy4ul84cuzVXXbpJegmxRi2kdguhGJjR4uJ43P0ynijVzYpc7 gnMSr8LefrkCrWiRbwl7v+8j+SzWwfipgw== X-Google-Smtp-Source: AMsMyM5KguWPdnmUe6E8V/9NoYK5gWcLWFgnAE6361jBUXNt3GQx0CXmaSoDi6Dm/CpcgRvw2hUgnA== X-Received: by 2002:a05:620a:3194:b0:6fa:192:62e4 with SMTP id bi20-20020a05620a319400b006fa019262e4mr1986071qkb.347.1666902700292; Thu, 27 Oct 2022 13:31:40 -0700 (PDT) Received: from mail-yw1-f181.google.com (mail-yw1-f181.google.com. [209.85.128.181]) by smtp.gmail.com with ESMTPSA id j66-20020a37b945000000b006f87d28ea3asm1570118qkf.54.2022.10.27.13.31.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 Oct 2022 13:31:38 -0700 (PDT) Received: by mail-yw1-f181.google.com with SMTP id 00721157ae682-36a4b86a0abso28091267b3.7 for ; Thu, 27 Oct 2022 13:31:38 -0700 (PDT) X-Received: by 2002:a81:555:0:b0:36b:2d71:5861 with SMTP id 82-20020a810555000000b0036b2d715861mr27546294ywf.340.1666902698189; Thu, 27 Oct 2022 13:31:38 -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> In-Reply-To: <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> From: Linus Torvalds Date: Thu, 27 Oct 2022 13:31:22 -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@kernel.org, willy@infradead.org, Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrea Arcangeli , kirill.shutemov@linux.intel.com, jroedel@suse.de, ubizjak@gmail.com Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666902701; a=rsa-sha256; cv=none; b=E6hgV1cZg/pxGriB3LXp1Z608YAr1s7pzoQ+NIUnig2wiuLfpkE4xzSFACmqGhqtdrUs6D PNRiSHpmRCFdHeDd5oNf4gJ3dwR76MEZnSQI4Rn4v1g1uJrEkjBnynefmGf4pcTYBhlwh4 5mX8HsbpeJ7ZXOD88AFw4Iy4Enja7uY= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=f3ObglpS; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.180 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=1666902701; 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=40/NzUhqBfpBB930IrYklEEa68Z0CgmOyOOoo4pZLBo=; b=P/PO3FRvddqrmZxoQ/1VsKhX8VtbWQWyHM5sztcwblHG9ZBtJpG1454X0uZeKZvVAQVhg6 S9ULjUhu13cW3hW1oDe4nfa612HRYxH4Ew8jTry30EMskw4HaVh1ghXSeNti/XZlnd2rOB sj22veHBMufUr2IwWwJn7wSBpJpnsUo= X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 6AACD8003F X-Rspam-User: X-Stat-Signature: xao5cri6i9c3a3mfg4htcqjbs8escuxo Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=f3ObglpS; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.222.180 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-HE-Tag: 1666902701-250438 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, Oct 27, 2022 at 1:15 PM Nadav Amit wrote: > > I think it might be easier to come up with new rules instead of phrasing the > existing ones. I'm ok with that, but I think you are missing a very important issue: all the cases where we can short-circuit TLB invalidations *entirely*. You don't mention those at all. Those optimizations are *very* important. Process exit is one of the most performance-critical pieces of code in the kernel on some loads, because a lot of traditional unix loads have a *ton* of small fork/exec/exit sequences, and the whole "do just one TLB flush" was at least historically quite a big deal. So one very big issue here is when zap_page_tables() can end up skipping TLB flushes entirely, because nobody cares. And no, the fix is not to turn it into some "just increment a generation number". We want to avoid *even that* cost for the whole "we don't actually need a TLB flush at all, until we actually free the pages". So there are two levels of tlb flush optimizations (a) avoiding them entirely in the first place (b) the whole "once you have to flush, keep track of lazy modes and TLB generations, and flush ranges" And honestly, I think you ignored (a), and that's where we do exactly those kinds of "this case doesn't need to flush AT ALL" things. So when you say > The thing I like about this scheme > the most is that it avoids relying on almost all the OS data-structures > (e.g., PageAnon()), making it much easier to grasp. I think it's because you've ignored a big part of the whole issue. Linus