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 593F7ECAAA1 for ; Thu, 27 Oct 2022 21:44:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B88E6B0072; Thu, 27 Oct 2022 17:44:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 468846B0073; Thu, 27 Oct 2022 17:44:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 330916B0074; Thu, 27 Oct 2022 17:44:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 24E096B0072 for ; Thu, 27 Oct 2022 17:44:51 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id CB9D2A015A for ; Thu, 27 Oct 2022 21:44:50 +0000 (UTC) X-FDA: 80068059540.06.0487E30 Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) by imf23.hostedemail.com (Postfix) with ESMTP id 6C2FB140034 for ; Thu, 27 Oct 2022 21:44:50 +0000 (UTC) Received: by mail-pj1-f45.google.com with SMTP id ez6so2927144pjb.1 for ; Thu, 27 Oct 2022 14:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=1SmucxEaYv462cDhUuWHbqENmtRj5EFJFsejZah/7ns=; b=g0FRESr+JzZQ6RWf4EVze5xqLA4Ba57sN9s5bYeQSEcmq1ESoV0OgMbslUIXTLlK9Z IwgDww9Z2P7g5HJ+UMcQAJtr8IVUt0fb2vcldKTrzRligsUdszod3BwgYyofJNRCJX16 mJkFiuJCGN4rzu9umDOaSxr1of/fTbFBVYeTcPXMeNxPjstpECua4fLrW79NYNiNnDPC zvs8PkY6UzdGsdP7BlhdPPOyHvpB/Fa41GSAyNo1vkqKEaZOiv1whR4HprvLg1ILwv8i sD3U+OGImOH6Hd8qDJv235BmKjoGCHnO6w+rAhGeu08bo8Bwd1yRhRz3m8NWZoPgBfsP 5BJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=1SmucxEaYv462cDhUuWHbqENmtRj5EFJFsejZah/7ns=; b=cU1VoC0nz9d9QTZei0HfDPxua2SmKTaLb2rqCDMmljHnJg0w+xc97SgAx0btM4EqZ0 cN0z0rIr0VwpaWh1uEBMa8Nx1aOwKHkegD93vUkzZaCJzBkqiwTC9Hmsargvwog26JRK DixzAMyjBrZO6Je/V0HkRoY8aDjwfVo82+RxsXllbRCCo4nGykaJpgqPbsNpf089prcZ +RMKQkj7t8nHb9/Z9exdljdm2eFie9VfUZZNUW5iBZwi6dVOG+JnOJWAYNKLhxdNYaQe qXE7x69RrsbD93V5vheRXHcAKy45mbESRE8BEpOcjvTnCIAaNeFS8gCPJZgvPk1xgWke FA0w== X-Gm-Message-State: ACrzQf0vjf3FIg1m0sjInpvRls91G1Z8QjAJjYU+BjW3Ie7+Q9Kf47rd I3ScfK8muNp/dak/P+WIZQQ= X-Google-Smtp-Source: AMsMyM502ZgWe6Y6XrEInBuJr5eDwisEYkmj7MqpseG0x7O/1U4H5ODiVYJYXzTs4G/s1zfaBkwvwQ== X-Received: by 2002:a17:902:d2c1:b0:186:9e90:6ad with SMTP id n1-20020a170902d2c100b001869e9006admr25862913plc.2.1666907089086; Thu, 27 Oct 2022 14:44:49 -0700 (PDT) Received: from smtpclient.apple ([66.170.99.95]) by smtp.gmail.com with ESMTPSA id j6-20020a17090a840600b001fb1de10a4dsm1394712pjn.33.2022.10.27.14.44.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Oct 2022 14:44:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment From: Nadav Amit In-Reply-To: Date: Thu, 27 Oct 2022 14:44:46 -0700 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-Transfer-Encoding: quoted-printable Message-Id: References: <20221022111403.531902164@infradead.org> <20221022114424.515572025@infradead.org> <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com> <6C548A9A-3AF3-4EC1-B1E5-47A7FFBEB761@gmail.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666907090; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1SmucxEaYv462cDhUuWHbqENmtRj5EFJFsejZah/7ns=; b=Uo76nMAUyo2G8Q7Oi4G9T+rjthOdvpLTWsgCjbBPcSzpJnL+wFXGetYHKuTFjdy3y3IJqd szEgtLcafe7zYxDam2luwQdu4QmrhiXnlmmx1YnIRp95Lup9XBddquMRcsjO/N6D770E9a qtGxpeWdxc72RkGAGORzch0O1h/p3DE= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=g0FRESr+; spf=pass (imf23.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666907090; a=rsa-sha256; cv=none; b=8Upfxp5J8nI9gfRZ5tlVXXoYL9NyzQaJahDNuveC5geF9+sFktCNorX07ztdfAb9arCoMK jhSjaQh268YvX4IkRrIijTVN8I2OhhBshk1W/rpWh/4SeRoWxHb2ZQpBLsxS4ZeP2CGoZy MtFE3KqEZNMLYiDt2bI0vn07danIS9U= X-Stat-Signature: rtmoekz17ao13dxksu5f79nq3nef8w6y X-Rspamd-Queue-Id: 6C2FB140034 X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=g0FRESr+; spf=pass (imf23.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.216.45 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Rspamd-Server: rspam04 X-HE-Tag: 1666907090-347859 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 Oct 27, 2022, at 1:31 PM, Linus Torvalds = wrote: > So there are two levels of tlb flush optimizations >=20 > (a) avoiding them entirely in the first place >=20 > (b) the whole "once you have to flush, keep track of lazy modes and > TLB generations, and flush ranges" >=20 > 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. I did try to avoid TLB flushes by introducing pte_needs_flush() and = avoiding flushes based on the architectural PTE changes. There are even more x86 arch-based opportunities to further avoid TLB flushes (and then only = flush the TLB if spurious #PF occurs). Personally, I still think that making decisions on flushes based on = (mostly) only the arch state makes the code more robust against misuse (e.g., see various confusions between mmu_gather=E2=80=99s fullmm and = need_flush_all). Having said that, I will follow your feedback that the extra complexity worth the extra performance. Anyhow, admittedly, I need to give it more thought. For instance, in = respect to the code that you mentioned (in zap_pte_range), after reading it = again, it seems strange: how is ok to defer the TLB flush after the rmap was removed, even if it is done while the PTL is held. folio_clear_dirty_for_io() would not sync on the PTL afterwards, so the = page might be later re-dirtied using a stale cached PTE. Oh well.