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 BB2A8C4332F for ; Sun, 16 Oct 2022 05:31:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83CB06B0072; Sun, 16 Oct 2022 01:31:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7EC056B0075; Sun, 16 Oct 2022 01:31:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B3F96B0078; Sun, 16 Oct 2022 01:31:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 57D536B0072 for ; Sun, 16 Oct 2022 01:31:49 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 28B91A0656 for ; Sun, 16 Oct 2022 05:31:49 +0000 (UTC) X-FDA: 80025690738.29.559D9BF Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by imf07.hostedemail.com (Postfix) with ESMTP id AAC0740027 for ; Sun, 16 Oct 2022 05:31:48 +0000 (UTC) Received: by mail-wr1-f51.google.com with SMTP id j16so13629905wrh.5 for ; Sat, 15 Oct 2022 22:31:48 -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=9D55kcxJPfSr4uC7lrTBeIrdbazIcQsUG0uBUHU+RpE=; b=RvAjObri22TFWIEm1z7bKNe1iq3npeuDeXgDJ6ccka3jO2O5Awq26AykZI/CkElPKI oOis1ogoCJVAAihsJuxwyKBgaicfVIFOA5AmC4e1u+H64P6F4yJq5OThF9apID2R0SjX Zy2Fwld1z7GBQHf2BRP4JIptqwoQYdzveu8ot/iBpR2+p5urSO8lYmOOOk6FBNrzWTnd evgsxu8vLB6I7CFbXdtn+dsI8ci5lIboIWd4KF6/baO7/i/EOjHzsewnUGocTk8cN+iq o0lnZf+71dLla3WGEP6Bdk1EVL6He4g/iuxcSfmzkODAVjmumVmZL4q+nEfQ2tBmXGcP 3vXg== 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=9D55kcxJPfSr4uC7lrTBeIrdbazIcQsUG0uBUHU+RpE=; b=i+vy5c2EnBfCQ9/yI47lOY71oJST/f2Tcp+BRYISus/yz18znu/EhcYLhGmPW4eWek xE5F9/mQq6TFVtexrYaCb3D61KMcSX2gThYLvRjOsd2mpXEnKD+qJ09h0S6e4xadzzaK 24q2ppFvthFGyUw/haJsv6B3Q6nBhV97pNXC4gkUevJfkSi/whfNCWr3naYk/fgBIGyD xGau49s8ZwesgjuV+FnvQtwOMcRzXmvSaxH+//cyhkUFxw5hSn03vyMpu8+3EMHlOBl/ r8h7IM6LV/ZfIboVHvcJfGdoKWWANnKdvB9jKyhWsAq7huqJ+T6G5hJ2ddZj08uyNUzN UE1w== X-Gm-Message-State: ACrzQf2xd7Xm5qat59vPyW4+xfMdUkx1C6fiqe/Ld3T92ivg6FrnCDCK gbPapkUtApL8yr8+FOgRjSU= X-Google-Smtp-Source: AMsMyM6ViCpN6wr5owNw5is0YYv4UENj8HWI+Ly8s+gNySpEGBC2dmExXe5kSfIObdI4/BDq57i5hQ== X-Received: by 2002:a05:6000:2aa:b0:231:ac4f:196d with SMTP id l10-20020a05600002aa00b00231ac4f196dmr2708249wry.121.1665898307032; Sat, 15 Oct 2022 22:31:47 -0700 (PDT) Received: from smtpclient.apple ([77.137.77.214]) by smtp.gmail.com with ESMTPSA id k5-20020a5d6d45000000b0022e57e66824sm6459092wri.99.2022.10.15.22.31.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Oct 2022 22:31:45 -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: [BUG?] X86 arch_tlbbatch_flush() seems to be lacking mm_tlb_flush_nested() integration From: Nadav Amit In-Reply-To: Date: Sun, 16 Oct 2022 08:31:42 +0300 Cc: Jann Horn , Andy Lutomirski , Linux-MM , Mel Gorman , Rik van Riel , kernel list , Kees Cook , Ingo Molnar , Sasha Levin , Andrew Morton , Will Deacon , Peter Zijlstra Content-Transfer-Encoding: quoted-printable Message-Id: <2C85D898-7D10-4E5C-9B2C-017B202C7026@gmail.com> References: <0484E294-D6D6-45CE-87F7-5AFDA5309BA1@gmail.com> To: Linus Torvalds X-Mailer: Apple Mail (2.3696.120.41.1.1) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665898308; a=rsa-sha256; cv=none; b=0yfoeKgZ9u7f9wAurJGuHKiSxj+XLxUFzY7Uxo3YsyAupbidmT959Zgheqq0Y2ZOyhce2h duG+vTLGVT7/dmCYtsrCqxQcfFL2gtBVe0/pRATaTD0wnnqwlaGFyPd38ImO9XtBsrNrOv RlAGqXwWy5qdrIUQk16pqns6s8wGzKs= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RvAjObri; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665898308; 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=9D55kcxJPfSr4uC7lrTBeIrdbazIcQsUG0uBUHU+RpE=; b=Ag5e9E3zIUSb2ktgsXKvc3t8L6k8OG3oYvRmQloxGWXplBcoBuCZrFYR7oKYC+sxmmFA72 zr9ZTvTmIXGj2G3SB/eh/SdgjGQPd3XdgVt4EYHBRFlUPMkegGaXpOTVdo+nRunJIDDH81 MdvqwZJt5h9qOlSlLqksq/6+uAJWlco= X-Rspamd-Server: rspam05 X-Rspam-User: X-Rspamd-Queue-Id: AAC0740027 Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=RvAjObri; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf07.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.221.51 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-Stat-Signature: i1883jh697nmcxc5a86ws8drge4eq1j7 X-HE-Tag: 1665898308-660575 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 16, 2022, at 2:47 AM, Linus Torvalds = wrote: > On Fri, Oct 14, 2022 at 8:51 PM Nadav Amit = wrote: >> Unless I am missing something, flush_tlb_batched_pending() is would = be >> called and do the flushing at this point, no? >=20 > Ahh, yes. >=20 > That seems to be doing the right thing, although looking a bit more at > it, I think it might be improved. >=20 > At least in the zap_pte_range() case, instead of doing a synchronous > TLB flush if there are pending batched flushes, it migth be better if > flush_tlb_batched_pending() would set the "need_flush_all" bit in the > mmu_gather structure. >=20 > That would possibly avoid that extra TLB flush entirely - since > *normally* fzap_page_range() will cause a TLB flush anyway. >=20 > Maybe it doesn't matter. It seems possible and simple. But in general, there are still various unnecessary TLB flushes due to = the TLB batching. Specifically, ptep_clear_flush() might flush unnecessarily when pte_accessible() finds tlb_flush_pending holding a non-zero value. Worse, the complexity of the code is high. To simplify the TLB flushing mechanism and eliminate the unnecessary TLB flushes, it is possible to track the =E2=80=9Ccompleted=E2=80=9D TLB = generation (i.e., one that was flushed). Tracking pending TLB flushes can be done in VMA- or page-table granularity instead of mm-grnaulrity to avoid unnecessary = flushes on ptep_clear_flush(). Andy also suggested having a queue of the pending = TLB flushes. The main problem is that each of the aforementioned enhancements can add some cache references, and therefore might induce additional overheads. = I sent some patches before [1], which I can revive. The main question is whether we can prioritize simplicity and unification of the various TLB-flush batching mechanisms over (probably very small) performance = gains. [1] = https://lore.kernel.org/linux-mm/20210131001132.3368247-1-namit@vmware.com= /=