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 8DE17E7717D for ; Mon, 9 Dec 2024 12:04:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2203B8D0050; Mon, 9 Dec 2024 07:04:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A97D8D004C; Mon, 9 Dec 2024 07:04:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 04A108D0050; Mon, 9 Dec 2024 07:04:53 -0500 (EST) 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 D62028D004C for ; Mon, 9 Dec 2024 07:04:53 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 54EC840ED4 for ; Mon, 9 Dec 2024 12:04:53 +0000 (UTC) X-FDA: 82875288846.16.BBCB887 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 4C701100014 for ; Mon, 9 Dec 2024 12:04:28 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ev3wyfKc; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733745881; 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=8ozULsLWQO+vzCljXTI+v97uJ+n9WOO7i0CyLv4/O+g=; b=w2e+/vjGGOEqAdTZtBbrwXeNCYHOlRVXmCKSFahX30MgpAImCPDQtM+t7ieDBF8I4+akZy 9Fu2IbJ+rspADJaslEXWXHaLzz7CXGU7fWoHWtXpwy/unNWTzzyx5Re/HcCHj0WI2+NbRW 5ctdBHYO+0em1/RxeVFAvsSirr5N83k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733745881; a=rsa-sha256; cv=none; b=K0ID4NG+EkCrQUzg22/FHbrsXTZT29FpnMxNcfYOVeDOBVWEGBxcXnweI/L+B7XJLPhSd6 IJhxIIoauF/NC9/uySbQZDXPIo1FJ4axjyca/Aq5cfi1EihJU1tspfL+xYiwJpAjO5HqTI 1+0ccjNkRbE1OAm+yZ07dFSZoWDdNCA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ev3wyfKc; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of vschneid@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733745890; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8ozULsLWQO+vzCljXTI+v97uJ+n9WOO7i0CyLv4/O+g=; b=Ev3wyfKcZldxWELeAdDChfmG6a2mHotpEByJ5aQv4wo4FOF6CLFjVhxqfhBPeJ14WHUDRU mByafu9PStkNbNLznDVT+4DWyZ+3G3TkIJOO8fvLzFg2oD9nNW9DjBYQCg+Xc8vFjSdQId flI2bRb7MjiRrVDULRUzOznGwqtbGdY= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-4LuXcKpkNHSrEZogNLZp5Q-1; Mon, 09 Dec 2024 07:04:48 -0500 X-MC-Unique: 4LuXcKpkNHSrEZogNLZp5Q-1 X-Mimecast-MFC-AGG-ID: 4LuXcKpkNHSrEZogNLZp5Q Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-434f40667e5so7554935e9.1 for ; Mon, 09 Dec 2024 04:04:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733745887; x=1734350687; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8ozULsLWQO+vzCljXTI+v97uJ+n9WOO7i0CyLv4/O+g=; b=akOEcryB6mNnGVmyjobUWrZizqzHDwWqbH2sgTAUHWdSPnXtMZZ/bk4YBZ4lfutsWy hJqIZeACoUmltcJ1s1ALFNdfYtiw3a6KRReHSkep7/99Z0gR+OTxknjTC4keibinmigo UblEpiLKM7Hfyss/N1aUYOBs5F+PSvy/906lJ8TWOA27STb3Quz7jGNJcTEl1pag9gTH JeeoBFv1SD9r5CM97fA5GlvOJMOujvdSS1tGEvtWbAro2dmfyqEAFH8LVfEzvJ36sIiQ OlLLlE64pAgFMYrPVbrIfp4xCAsxmUpwbsW4TFxDGwGLPEf3ANh9+txfRficT5wSH4Mg vSbg== X-Forwarded-Encrypted: i=1; AJvYcCVgvd4XAdKyU6u6LxD2/Mt1x7hzykna0CocItb9OmBCdppz8q+TJbcrMQKA5ExD/nlwpG8U4qLjYA==@kvack.org X-Gm-Message-State: AOJu0YxDou+JW1PuPrNw/yN19fKu1fFn4Ah9YrPCsFr0NG/TBLFiIpFz 6j16tbb96BM/sFdpv096J+a297Ywg3RK9OTPUBdtqdpVs/uoMJkIoD6aK/nUyUSRB+Y28203jKe KcvmxFHGYU6X6qR4hRiRuKdUQVnP+HEiVU6WSVWcKhc9gTcEM X-Gm-Gg: ASbGncvqlQhXmgnSk5hWr9XCscTKacK0VtKSpxkEiHhLLqW6Tj+c6hby2teIgFJEULf 2Ohut55jtTDGTIhlDaUgyf4jSZmf/5ALNv/khBgSP1U5aP/G6ebnCTK1SrhgvkTtmOFPLQk6Zo/ BxFiMDLCCl695zP1sn4xfXluIXP/9OsxEtm4dTao8NGZsCXOa5TcbnXo9gE25iPDTNjE0Hl9HZD DA3FuF5ReCkLaVzdcQz0Ha2yF7CYJifDlRPyWyiPVR0G7HV6F72B5y4NUfrD1o16o1MoZkxtMHX Tcoxbzpb2lcltupn8JtD480JbY2wVrYOn7M= X-Received: by 2002:a05:6000:184b:b0:385:ed20:3be2 with SMTP id ffacd0b85a97d-38645401effmr26627f8f.48.1733745887080; Mon, 09 Dec 2024 04:04:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IH7+TwyI4hfJQ4uZRNXBuUPLYNSzp/LJUZ4222u4bGFUZ10ecblUvGELIouY8pa5AFUG5gJsQ== X-Received: by 2002:a05:6000:184b:b0:385:ed20:3be2 with SMTP id ffacd0b85a97d-38645401effmr26553f8f.48.1733745886668; Mon, 09 Dec 2024 04:04:46 -0800 (PST) Received: from vschneid-thinkpadt14sgen2i.remote.csb (213-44-141-166.abo.bbox.fr. [213.44.141.166]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-386408549b9sm2359972f8f.89.2024.12.09.04.04.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Dec 2024 04:04:45 -0800 (PST) From: Valentin Schneider To: Petr Tesarik , Peter Zijlstra Cc: 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?Q?Wei=C3=9Fschuh?= , Juri Lelli , Marcelo Tosatti , Yair Podemsky , Daniel Wagner Subject: Re: [RFC PATCH v3 13/15] context_tracking,x86: Add infrastructure to defer kernel TLBI In-Reply-To: <20241205183111.12dc16b3@mordecai.tesarici.cz> 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> Date: Mon, 09 Dec 2024 13:04:43 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: DZwojuwG3yXFbFW3v2lEYqx1ijy1VKzn5_9XoO6KMZM_1733745887 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Stat-Signature: ktgrttz9zek54yr7qb4xtnb4kn45b1ha X-Rspamd-Queue-Id: 4C701100014 X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1733745868-828965 X-HE-Meta: U2FsdGVkX1/S2ksaAOrh77Kk263Ietd55thvzh0jMe3EEGUsyqZhRQspbz8UQ6f7ja5QoBo31vP9ystYv+HJ6rrC0isFUxcirxjBvXyKsbeczG9BjPNQXpk80BvOX3R9EaTAhyW9FN1Gkoi9D5sJV5gak1aTHoZN36APgaDxcZvFDqVJ+2hsxcVv3DG/1KwzVhM4UO50O5cHYZ1vwuohN/eegCEbz5KSLdN59gWKlBSAcoA3PHffjrwbICeGcpJurypeyZ2gUuGTJAzx608q+LhBxgUTnRkk6HeNLRWh9hMtKm1ozHKzeHtZtnfjRsR8IfL6mUHeoGSmbabz6/lIe54TXge2+pKZEN27nejsXeHX/g/ntggvuGFXZgp9TyfoQ77mzOZ9nx38L7Vhaz/LXhkRoKeU1/06iqFtmfshO8X8zThaQuv3r5WESFV7byytbcjYoOdZfr3qf2U/pbMmOh8zYkdknydOGdM43b5Nejr9ShOkOjfri07/ZKJLB9ZH8wKliKQ0s698WlQ1l67Pwftd50vRgwUWypphUj+/c2GvDSsXY1FioGfFTOH5ngKe1bczmiwrWKHvIVKRrx8Cs9B+fpKi5/MJ+C7uFbWlIe0IClHBD9cMDX2ygA9msnHFh9JKyIGVq2FueV0SjX9Si2kjbMF4oRMpjH6RgOTBrxJ090UEF8d4vxjFcUosHj5gTYMBHClkLyU27vpQTbJDCSO8it4xJ252cxTWLoQw+lyYQwyEdQRzWav1KwQnRIadFjzlFREkt3mB3vgOxrOuld51SItTW4uGKyKSNoYJJ8uZZ/SmMwR150WYSV0/4XItUFTqWZdDO9sclE+8VR6uQbzcLrSvqYKuaF5crU95rhI5kbwtteusHxVa7A1tZ4MvRKR2OX6nLTsHT7NP7RZoDobnWFGkVu+RUXRpt5srXFn+StSfJbYzB8Ai89uqNA3xZjEL9blt/YlQe87piB7 MM4c7N/n B12AKwUx4M7JneHeI95LFJWQahrMH4sLSO07eywgZ/MnBVQF73ZuAjEht16dDacYKt2dVKjHH3+pdiZlvRhleH357UxAvSvFc3KU+fvhUt7EdabTMhISeiYUFe2Ne4JYRuK4+lZenkCnxysg55SNEIpZl5cmotsDbXo4QdwOeylOhTMSSGc2SxbFdw/kwaG/Q47hz8iI+UXl3HjipgTP5p5Iyqs9wVvzgz1fpvRMndsmbXcBWemrkcCsFyE9Hrz4veaIq1+XFIzPw+xQFyYN5LJdPq9K8jPqAwO/7cwDTyVN6qh+/oiRjjkHp+ynTQCBoFSW9V77gVXlZUrkUGZNoQY7by9Jqs3Qop/EeCj/4LTdDe5aPSqeMvroRSYb/cI+DyPpGE5A7YU9bE0HqQd8dycXvZe3mdaVYrBwHNBWL5bFNAHbQcarClus7GTbc/UqY2rpGSYWgg/NPJcy5TPyxAZCjfmE/LvyYD8GHvfgxQNOgg9s= 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 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. > Petr T