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 C083AE77180 for ; Mon, 9 Dec 2024 12:33:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 40E476B042C; Mon, 9 Dec 2024 07:33:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3BDF46B042E; Mon, 9 Dec 2024 07:33:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2859B6B042F; Mon, 9 Dec 2024 07:33:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 050226B042C for ; Mon, 9 Dec 2024 07:33:17 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id B3422C0484 for ; Mon, 9 Dec 2024 12:33:17 +0000 (UTC) X-FDA: 82875360624.02.E9E8092 Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf12.hostedemail.com (Postfix) with ESMTP id A0D114001D for ; Mon, 9 Dec 2024 12:33:06 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OqugFSMZ; spf=pass (imf12.hostedemail.com: domain of ptesarik@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733747586; 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=Nt1cndHZ8pbXtiRxeB+O52iETLBujQEcUgkGHWv3lYM=; b=nYftf3IBNk9nZ1BBvOMxoftiWH2Zj3cb2RVnVdku96ZApXSlOChVQJahqPkBepd8J03tu3 Pw6ECfQMQIlT+IuR3JEdUIlEt1EHAdkWNyaPu3+Ek/YAU63qQbWqr384ThrGOqguowrNaG by83ztD7Rb+IvXMwkqvBMgoSVMB02sw= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=OqugFSMZ; spf=pass (imf12.hostedemail.com: domain of ptesarik@suse.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=ptesarik@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733747586; a=rsa-sha256; cv=none; b=hQLxACxju//PKAP5UGXhksBy+09VK8dxUZ0qxL0zpILhdlh01SnDTLE0BKGVVbLvwYYIi7 35Oo50BbHDWlPiXVO2h4/aJj+wtgj+DWOSjfLyTVDHrolsphi8UPeoXcPV+/yl7jWMNmR8 A5y4mxCgl8WLPviwrk22jdAWzsiUqQg= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-aa6935b4f35so7406566b.0 for ; Mon, 09 Dec 2024 04:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1733747594; x=1734352394; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=Nt1cndHZ8pbXtiRxeB+O52iETLBujQEcUgkGHWv3lYM=; b=OqugFSMZ5YXl7VJZ8iiQyYfAsWtQpjRKPTuLv+EnQ4UoFj1x9z3EJhskTmowROOSQD uivg7j+zJB9JxPyyOe5XnEGh/INF4BV8PNnPTgr8X/KK/U6HAQ7DVj+m0VAo6wHFzEoR 4LSPA6PePbG3WYMXJW3fIgwjqKpNL6SyRR8FWG0MFZJtpyLqDCfBcFbgKbyXKHrBurPk zz58S3oPNsRVWumwqTb+wq2OdKHYKsXgxkGb4R2pVNWIDrP/KU1LNCGZqqbyiRpmjesv vrH9jgPfeMGmxEl8dTdBHXJHkt3yO9LOs3ofYdg3cMbXPeau1g80ovrpo9QFJ4xH9PgK W04g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733747594; x=1734352394; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Nt1cndHZ8pbXtiRxeB+O52iETLBujQEcUgkGHWv3lYM=; b=QTyk1RpLNjbY3Cmsb7UL1G4eYGZ8epo5CgX/yIGofegYV1TbKjUMraq4FteGfzQV1q 7fB41kVW/cCnpDadzIEfSe44x8tRTJcPKmz+qGVMHSvWw4b1c1QbDC7X7b73Tvrhr5Pa BVkGz3UxwEkDNghhPm/LRoiGSIq3Pw7XtuWGa1Yg7iMocCRi9TSltzDa4ExAZQz2kPVp JiGeP005hOimHDEuiyY3sABxxFZCm/BMC4xdl+Fc2X2ofgbl1Lxv35I58coY9tHxnCfh kiKtwVX9+n+wXFPjx3YmCB6+Au8lhJDedAE0u5iA6/8fk7u7YAYXDINcRG0eVzdTAKhH jtdg== X-Forwarded-Encrypted: i=1; AJvYcCXfXOPSYErKQj9rYRfBI0GEYeWtx+LJ1P5w4OlDDTGxrBhaxQd96Yq8g20DhDMGG9qzomFhORd9kg==@kvack.org X-Gm-Message-State: AOJu0YyBAlG9j4/PvRgx0Le/jiqW8O2JtWtx3ITDXAu/oh5hth8P01/W J0WdITxOD+wkx4HkJPapzVruHiUirnxH1jxi0UMiyexTpSDU5Sf1n7xK7Gw7Wwk= X-Gm-Gg: ASbGnctzQ9oiT275k61eG1FwJpFj0AUg2s2sPN+33GBFDIbuZ8Lk9YM1FLURm3IMaep ZIdhGp0osN9yKcyx4x0BTn/B7HUm8bNeR7DTXKg28/NtEE2gWJ2A/jZ30meGA0MPO5WfHJjBLv0 hIQUMbWd3K3xcRB94mWnTnEm3VjzumCvXKlri7aAJjYz9Azs8RPSg4rLe20vN+Zxcg325YDDGdj cBywtNQh1w8AXN2DLKEeq8oVw3kNK/7faLu3a/GvMdJ7c4H17pv+wF2csHBmHn3kL02J7k8/9zX Z+6MElFZwWBQCz5Q5zNDscWjNIza5Ga+9Fs6IH7QMJmqMwdUKDWkk3Y= X-Google-Smtp-Source: AGHT+IHhdX0FdatIb0ng+WxBrxtwY6KW2ibAnH43Vj2dTr2Rwd6wvnDl6sDEJjcdHu0Fke7nx/YjOQ== X-Received: by 2002:a17:907:3fa8:b0:a9a:8216:2f4d with SMTP id a640c23a62f3a-aa639fa5dfamr461325766b.3.1733747593866; Mon, 09 Dec 2024 04:33:13 -0800 (PST) Received: from mordecai.tesarici.cz (dynamic-2a00-1028-83b8-1e7a-3010-3bd6-8521-caf1.ipv6.o2.cz. [2a00:1028:83b8:1e7a:3010:3bd6:8521:caf1]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aa62601b5fesm672536266b.117.2024.12.09.04.33.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 04:33:13 -0800 (PST) Date: Mon, 9 Dec 2024 13:33:09 +0100 From: Petr Tesarik To: Valentin Schneider Cc: Peter Zijlstra , Dave Hansen , linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kvm@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org, x86@kernel.org, rcu@vger.kernel.org, linux-kselftest@vger.kernel.org, Steven Rostedt , Masami Hiramatsu , Jonathan Corbet , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Paolo Bonzini , Wanpeng Li , Vitaly Kuznetsov , Andy Lutomirski , Frederic Weisbecker , "Paul E. McKenney" , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Andrew Morton , Uladzislau Rezki , Christoph Hellwig , Lorenzo Stoakes , Josh Poimboeuf , Jason Baron , Kees Cook , Sami Tolvanen , Ard Biesheuvel , Nicholas Piggin , Juerg Haefliger , Nicolas Saenz Julienne , "Kirill A. Shutemov" , Nadav Amit , Dan Carpenter , Chuang Wang , Yang Jihong , Petr Mladek , "Jason A. Donenfeld" , Song Liu , Julian Pidancet , Tom Lendacky , Dionna Glaze , Thomas =?UTF-8?B?V2Vpw59zY2h1aA==?= , Juri Lelli , Marcelo Tosatti , Yair Podemsky , Daniel Wagner Subject: Re: [RFC PATCH v3 13/15] context_tracking,x86: Add infrastructure to defer kernel TLBI Message-ID: <20241209133309.794439ca@mordecai.tesarici.cz> In-Reply-To: References: <20241119153502.41361-1-vschneid@redhat.com> <20241119153502.41361-14-vschneid@redhat.com> <20241120152216.GM19989@noisy.programming.kicks-ass.net> <20241120153221.GM38972@noisy.programming.kicks-ass.net> <20241121111221.GE24774@noisy.programming.kicks-ass.net> <4b562cd0-7500-4b3a-8f5c-e6acfea2896e@intel.com> <20241121153016.GL39245@noisy.programming.kicks-ass.net> <20241205183111.12dc16b3@mordecai.tesarici.cz> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: A0D114001D X-Stat-Signature: nehaofez45izgnttns91c5gdccwrmqws X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733747586-883699 X-HE-Meta: U2FsdGVkX1+WzqP3ZQLTJMXo/eUu6EAafv9sjn/wrABlSsnmstvgxYjyZ4j4OP5j78n7Gnkbj/umf7iMS+r1t9TEZUOkmAdsKGidP2poAxzONPklo5WtG/LUH+O41KXJlYKnTMsoofoe3mCyUI3cwNrzIENsLL9IQQjse4X1m6hzHinIQ87W+Nh+RUvVx+p8Ci2ZeSSW4uaU8z64fqS7jet7qcfOAXPyhvXs2ooRcor0z8KcrdJENYR0FTF+Ps+y79igWiqcVad4LUs2qUhN/aA4p8SOobdjbTlQjIrqdwU7H3Q1i76nn5V0//HlDVcOnp8ptoxaQX56i8lqyVMd8mU3xJyooxEh1TuDUkQT1q/RXnKa1FDGJtsDyOkRju4DjaKKNPVnZy9xdTvk6hFs+IgV9yhVk03zwZ28qS7Yrw6q2pH04tf14d7/AJkd85MrXA4/PuGK9nJ+Lc+Zl6NR8YXsJHuzOzMuVt8zMLMAcjLGGlJk4vEPSU54T+5682ONW7L9+EpbnzUABxaNJI5IsFU6sNO2CGIc6NT1lw+dpMtKw9da5DWUpM/bU/QSBfBmrSXZTnm22TiMOHHWq6vtptOHzH5RuIsPPOfIPOOr0MOMR7p4ULORnL127FAxYlVKFe1ITGBSLJmEhCL5wXA9nQZ7GHR6a2lk6c5x4apAevJYAIG5GhdtH574s7CVSaqqKVi0WJJ+/f3s2YqtpwpNO79tepWPk78u31pnFF3iqXQdEFhhuPKYfScP1Eqobc+EbqGzWhj3KS586+YJ5o7EPm858GT6ceqzsFFO90bZElSxd46iNNSbfV5h8H9+EDeP3fZRu/yi9quHtY1l4Y2AFz3P/2+59/X2t7Jlg2HDTbMEGl+ixwhsJVsXx6I+kUt05py7JIaVggFQoKffAUN6f28UvEd4REABXrfjMbgk4ndMIAmgh0guMYAg75ZB6IpKVx5pYHPCxcE+gxtw25i V/H466xo xbZX3dVTWF5V8+TeEnpWNNXbmwQQ76qrHxD6eHKlpg5RGR4MhAqvQ6Wc98YH0k+F/nBdScmuIOj+StunZJwDotznqN+e2kC2Yz58ONaF1KdVT9bnkCzw/fjFDipeq3+mO/m5B0OAEWnNNFoKB2waUeBmZItglZFH+BI1UWZd5Sc61VdBbkW9Y3n4TNoc74KwnFWT/EIBrUa08oiVHPoBlMCwfKKTpLaXFx/mX1u26Rk4RYYhzHiKRw3EClIOnuBgxvnNWTkINkS4bUmm3t5fTOc03fSw75dnj/v5yGFnmqJh3v+YgwKvP8pXSp6OnWMyjTkYpiXocC9Mt6+KxNNXhhLdy9HyCiIQm9dWqKGWkaItAATRESyEtpk9BBuNzXEeYxLo54Ho0/aWZ/xdLdrVJ7HaDX3Yfew63K6HLV9r64v2yhQM= 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: List-Subscribe: List-Unsubscribe: On Mon, 09 Dec 2024 13:04:43 +0100 Valentin Schneider wrote: > On 05/12/24 18:31, Petr Tesarik wrote: > > On Thu, 21 Nov 2024 16:30:16 +0100 > > Peter Zijlstra wrote: > > > >> On Thu, Nov 21, 2024 at 07:07:44AM -0800, Dave Hansen wrote: > >> > On 11/21/24 03:12, Peter Zijlstra wrote: > >> > >> I see e.g. ds_clear_cea() clears PTEs that can have the _PAGE_GLOBAL flag, > >> > >> and it correctly uses the non-deferrable flush_tlb_kernel_range(). > >> > > > >> > > I always forget what we use global pages for, dhansen might know, but > >> > > let me try and have a look. > >> > > > >> > > I *think* we only have GLOBAL on kernel text, and that only sometimes. > >> > > >> > I think you're remembering how _PAGE_GLOBAL gets used when KPTI is in play. > >> > >> Yah, I suppose I am. That was the last time I had a good look at this > >> stuff :-) > >> > >> > Ignoring KPTI for a sec... We use _PAGE_GLOBAL for all kernel mappings. > >> > Before PCIDs, global mappings let the kernel TLB entries live across CR3 > >> > writes. When PCIDs are in play, global mappings let two different ASIDs > >> > share TLB entries. > >> > >> Hurmph.. bah. That means we do need that horrible CR4 dance :/ > > > > In general, yes. > > > > But I wonder what exactly was the original scenario encountered by > > Valentin. I mean, if TLB entry invalidations were necessary to sync > > changes to kernel text after flipping a static branch, then it might be > > less overhead to make a list of affected pages and call INVLPG on them. > > > > AFAIK there is currently no such IPI function for doing that, but if we > > could add one. If the list of invalidated global pages is reasonably > > short, of course. > > > > Valentin, do you happen to know? > > > > So from my experimentation (hackbench + kernel compilation on housekeeping > CPUs, dummy while(1) userspace loop on isolated CPUs), the TLB flushes only > occurred from vunmap() - mainly from all the hackbench threads coming and > going. > > Static branch updates only seem to trigger the sync_core() IPI, at least on > x86. Thank you, this is helpful. So, these allocations span more than tlb_single_page_flush_ceiling pages (default 33). Is THP enabled? If yes, we could possibly get below that threshold by improving flushing of huge pages (cf. footnote [1] in Documentation/arch/x86/tlb.rst). OTOH even though a series of INVLPG may reduce subsequent TLB misses, it will not exactly improve latency, so it would go against the main goal of this whole patch series. Hmmm... I see, the CR4 dance is the best solution after all. :-| Petr T