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 390EFE7717F for ; Tue, 10 Dec 2024 13:53:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 804A06B01A4; Tue, 10 Dec 2024 08:53:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 78D2C6B01A5; Tue, 10 Dec 2024 08:53:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5B7DD6B01A6; Tue, 10 Dec 2024 08:53:46 -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 3B2D86B01A4 for ; Tue, 10 Dec 2024 08:53:46 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E3C761C74D1 for ; Tue, 10 Dec 2024 13:53:45 +0000 (UTC) X-FDA: 82879191150.09.D4C6E1B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 0F2B0120024 for ; Tue, 10 Dec 2024 13:53:12 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FljvzEpd; spf=pass (imf29.hostedemail.com: domain of vschneid@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733838813; 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=/HoNuqIEOrVRmdvjmLSRb9lrwGMQMrAipZHJQOxiwTc=; b=vAQlHT9YqIrUNGMX34BfuhBTymU7LR8lhodsPF0/+zef2NNr4but1u6YO5+nKHE4fprqaV ck2S+ZK497H2j5QC7mD+Sp7SgzVv5dGi8QjEYEsVwhxmGtE9Nz1zfE0sIvgN/RC1325va8 buagJFT3OHWgua/YOfX8QwOq55hkb08= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FljvzEpd; spf=pass (imf29.hostedemail.com: domain of vschneid@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=vschneid@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733838813; a=rsa-sha256; cv=none; b=4hIPGVECg6Dhuuz/BhPsJsNicC9KQpjOl8qGbgZUYXtQGFF1tBEV8om9yPnQBqJ4NdWx7v cdhLPd/1e0iPoNdO7gfZoEghOHb7UX/6NX1du8tRfrNRoQrnvM70qzlRNODsvueDibWRDZ gZkYTGACIsBA9DgmEwCJdtoE6b3+7Xg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1733838822; 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=/HoNuqIEOrVRmdvjmLSRb9lrwGMQMrAipZHJQOxiwTc=; b=FljvzEpdB06iFSwqoq1dkPV89rYKuiHy1SALKfidhlZjTENLVKB2tm9sNF7mQW+YcFjb1G FXhH3bSaWwghanPZqFScUVVrq5vOrFI/iEBs5voB5r+5B27aiR1fDBtLbO872XLEeZyLYB ZcVj/iES5YwiqFfOVqaWj7AGkVbKQ4A= 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-599-gR4JZR0pMvahHi5vLFssNQ-1; Tue, 10 Dec 2024 08:53:40 -0500 X-MC-Unique: gR4JZR0pMvahHi5vLFssNQ-1 X-Mimecast-MFC-AGG-ID: gR4JZR0pMvahHi5vLFssNQ Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-434f15b4b6fso16545575e9.0 for ; Tue, 10 Dec 2024 05:53:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733838819; x=1734443619; 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=/HoNuqIEOrVRmdvjmLSRb9lrwGMQMrAipZHJQOxiwTc=; b=Kwut8krMixtnJWB1Sa/UJt/t1fgAZ7T//kpsADKXTu2EEOGMaBnJBZ95eQFrdahUHu +y3HmVKnz5m0TpoDMw3I1V1kxEXm0jaVTYlDxDbr5AR6caG3IATfVW9EfqnYOFR8YKBp iX53o/+dU5CA72x2VWN0416D/UZ4UsR7Lo+ocG9Y6uCi26iyzLL/AukqqRkP0IiIHnJI pFeOvGVobl43oa/HTxH2yZg9yPFAXL87noQEkYcxLKXDqZJUHxlKq0xEaV6TS3gEhdWC rM2ePoWuzFRuQ8pA8JuuJ/A3jB3a0DX6TuKAYq+isihjsqiakiXpVXFrJ+ovawMk5byv 0GKg== X-Forwarded-Encrypted: i=1; AJvYcCXLjGX8wdaTnbRua1mc2Fym3Z1xIE/ZgLgA81lUJlfGIp8ls3zT4JJ4VLrZOxCsEushq/FEPi96VQ==@kvack.org X-Gm-Message-State: AOJu0Yzgypkidd9J14ldoTE3bARrh/JM+6KIZ2Wnk7Qu91ASPlDgctCL 2hAQN3lEWRlTOmR/9Aig67ont75rg7OMGc9NB9V/w5h2ESMq58vUyT5y7thvwiv/0pdB3svVFvG yUEgER7TtO3ic914+VdDp49HzaFo2Wd/+KxkS+3m42AQV0xIY X-Gm-Gg: ASbGnctnsyPMzU6v5D777BlEhrlRdpKql4EyoaaissRtPaaYvLvL0scZolbhpC1jBda BpBF91VUrf+cRAII6z/rS+U60G2xE8gi8QjpTNQTbhroURb51TNB/v5BM26klvuGIkfzaoQXH+H sz1eRC8XKBgJrmG3MeBlUnfLpimMa22BoAfUat8UckI1+TogvcbEOfC2AWWrky6ZV3gUZMTbqz/ ehFgPpih/be2ROjsOw7sXp2ks5fASgGcZimdfLNQdGFEPVO6vg+YMFUEPBPdue82BxLq6a7W3xj efaHrMBVPNS4SdVuMLAHln0Am+LBaoDhAzftK6c= X-Received: by 2002:a05:600c:4447:b0:434:a7e3:db66 with SMTP id 5b1f17b1804b1-434fffd0718mr34707715e9.26.1733838819518; Tue, 10 Dec 2024 05:53:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IGX1Bnu64mtb/xieDzhp74HQNT4+QKiGnwf7K+hTkAcz8zIBE2KO+I2nCgWMN/+kxkXTwBWJw== X-Received: by 2002:a05:600c:4447:b0:434:a7e3:db66 with SMTP id 5b1f17b1804b1-434fffd0718mr34706985e9.26.1733838819087; Tue, 10 Dec 2024 05:53:39 -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 5b1f17b1804b1-434d52c0dd4sm227972305e9.34.2024.12.10.05.53.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Dec 2024 05:53:38 -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: <20241209154252.4f8fa5a8@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> <20241209121249.GN35539@noisy.programming.kicks-ass.net> <20241209154252.4f8fa5a8@mordecai.tesarici.cz> Date: Tue, 10 Dec 2024 14:53:36 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: uto9r62BKBk2uo5l5mfkC4mca6qWSbkZx_tgj26ipXs_1733838819 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Rspamd-Queue-Id: 0F2B0120024 X-Stat-Signature: 9a9iofsb3fmg7acdwmj4jmewozqmchz5 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1733838792-784558 X-HE-Meta: U2FsdGVkX1/BDDLexU1IkKqL8vc4Jti4Ptxa1kkMAfRyPXxAyumISpC4vWXDIX3kIPbA/+fvgRgTzQ5qMeCZlJOEBwcNRaT0qhrgQKPyMWu9ZxWOFtz6707/RJoiOZpnKfYXb3ChUU4q1sh34ZSf2y8IawpKpIjN4DBE9beu/wWsiJMVoCrVfPheGs+4Mzo3/CK4paXuCnnFS2rJ3E7aDrBqWvxJhXhcF1jziwYAOU9OZ44WG5QEiiLyWVMFfJeWfUxu6cj20LxX7ixFqbcwfj8T1VvIXvBrGCGpqM35WlxCFKycO1eapZvgzfl5nqXYZW0xlhwtgjWsXfvQcIi2UuOugVtbQoOPZh3LBRu/yFzE9bYGYhb4ErM9krm2hL2XFFY18L85kiUd3yUj/Zzf6jVYOHEkBLoBH1yb8/USpBd9SWF5dJRraO4b5PNCy58n7mENXc5HN/aqSexGme5y5jYACMz/EVeIflvbM+uNIdLAru+8relU4W2ZRr+IifebY6TYuMDv4EmPOe59zr5TFFvkwvB+BhkHZFs/ZOo5w2eDzDm2od3HsBTpySoPECdWVXsz8iGH1zno/ouXMzz5vh3sij0lKGfbJh28bPDP3kagTLfLBoDUBm6Iih8Nlo7RE0Pbgj0vqh1g7sRJUlj9VL8yjVIEAI/kPOQWaHOgkysTDQrBWg70vn7SWDrvT9aUengLqTSWUpEODZwRTcsTxnWf+xyNv30JFzdKwcATmUOBRSgs/BHuhGuqN6Pi63akpBAVduyJH0puXkmgO9e54bZuLKzOuQHj3sOTlQk96Kn5lDGFjFyIDGmq0HkZ0MAaIAsxu5GzzWJIHp8vfQh3vtmjvHUT0L9FxCrbiGHdkTvX0jqQ0arID/DiC4ztWxCSXNiRUoL3V26ZPHkDmPaj9UOdat/+C7h9MiHhaYkZc1D8b0lMxKA32kGe8SXkp5GXIWjPw+sOIccPQccs7SR ytc50/Gn Wr0EYJqTNSR8H1RGs5k4ipI93FI7tsC+O9kEfbuFojtJql9l2Xd5vey8FUnD9ULSeD2gc4B7LkhRkRwdlvKupc1cLRpLScal8Lc5MLnPKXb5skglBH6E7e400Ns9LZ/sO3vUHrKz3pTrIhLs2r2fVxB8O49LuP91AeAj2M+U+iIa6Yb/XCm+WwhhySB0S2I6POsvMDyKt1+jpiGS+V5keTOigOnq/qSv2udSTAjotatqn7QU1VHQb3YloVz2eX6c8zdro+2sywuLUNspfEsLT08Afa7o/4d7ZgNObLjqU1obw/G9bUn/gIz247uJElOrYHzrC6WtFsSuYCoi0PMguLgyS3wj8yzDc5bIUwtYOfgxdCDEl3cjXdyBf+n9T6FZHryoypkTEdOA53lZzsiF1+hOzMaanHoGx+E6AjvhEGbgSblruOR/DqXMGu0GUfx00a2uHvXaZdTX4+DzX31Yih53Xf3U+MKrgK3+LctS9qVnjj50= 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 09/12/24 15:42, Petr Tesarik wrote: > On Mon, 9 Dec 2024 13:12:49 +0100 > Peter Zijlstra wrote: > >> On Mon, Dec 09, 2024 at 01:04:43PM +0100, Valentin Schneider wrote: >> >> > > 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. >> >> No; TLB is not involved with text patching (on x86). >> >> > > 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. >> >> Right, we have virtually mapped stacks. > > Wait... Are you talking about the kernel stac? But that's only 4 pages > (or 8 pages with KASAN), so that should be easily handled with INVLPG. > No CR4 dances are needed for that. > > What am I missing? > So the gist of the IPI deferral thing is to coalesce IPI callbacks into a single flag value that is read & acted on upon kernel entry. Freeing a task's kernel stack is not the only thing that can issue a vunmap(), so instead of tracking all the pages affected by the unmap (which is potentially an ever-growing memory leak as long as no kernel entry happens on the isolated CPUs), we just flush everything. Quick tracing with my dummy benchmark mostly shows vfree_atomic() -> drain_vmap_work() but pretty much any vfree() / kvfree_rcu() from the housekeeping CPUs can get us that IPI.