Received: by 2002:ac8:4602:0:b0:405:464a:c27a with SMTP id p2csp2536191qtn; Tue, 25 Jul 2023 11:33:26 -0700 (PDT) X-Google-Smtp-Source: APBJJlGmSwZrzixj5b5OXVcx0EADS0EAIHp0c9/ZXpQPu53UcZNXP4/Hcmfohtx2bxA+g0JxuG/m X-Received: by 2002:a05:6a20:968c:b0:135:293b:efaf with SMTP id hp12-20020a056a20968c00b00135293befafmr9589437pzc.10.1690310005884; Tue, 25 Jul 2023 11:33:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690310005; cv=none; d=google.com; s=arc-20160816; b=swlNOicNZf4j/nTzPfbeh98F2JpGDLYfeB1TyH0ry/dk2HHCuhWkMlEJSGdHhVoumB gzvQTBUHaZVQg966twZjwXawI6F0ExiIRbOrZ2zirtHY3iDllcWuFdW9VYCdZ/hl+EmM TtEaEEoJW2BviPNCmKVumkyAZyYCaCZH+C/YZq4DKA/tf7KhDZRkxL8HE9JVlwhKpkZS TYnQWg6Ipxe8nFdzTp9YL586LTvC6+qFgIgEi8MOE27/EQOHXUK84+Q+6AzjdThwVKYb A6eolCFBpZVcVMbJ66CDGgGTlEI+s2etUyNvpeGPaZUKPkrm1+MNO6mpsJ64riZLsRXN 84lw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=WJvVodEb8nnJEl20cUTyJdImyktiXScfem+69qgqo3Q=; fh=hP1cd/A29esKgbMqJvlYr2nmuPxsECD59uRSWeH9BFo=; b=nNAMBN/MeB70InJqTYc+m+Tpd4w1+xmfmYlQUjvYmkHCYgpIpNzIbn2cysODqJWbac JWpPjMexhYxH/qY0ExJEmnxFijjEAAOEg8afTSgFznMGuKmorOKxSaCYMLFdJiFZ7oOj LFhqABCT6i+/jlSvVweauAx25yzQTr8rSjZR5tWoPeOPDVMI9riGNuV9UKjNCdbLLn0O nUEyZ6AmpZkhZxrRk4PFuxl6wl3DgsO1S1aX77UAkQ4QuJEXbRhGbQG7RApRdDZC7i7D CBzWQoQFg9LctX+Npn1+R+5QTT3+8qcB9exQsJwL6w3M6rHuHbT/TRs+a14b4mc4R4WX pOZw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=e5ID1UqX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u11-20020a6540cb000000b0055c993fe858si11780394pgp.892.2023.07.25.11.33.12; Tue, 25 Jul 2023 11:33:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=e5ID1UqX; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232136AbjGYRlj (ORCPT + 99 others); Tue, 25 Jul 2023 13:41:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231302AbjGYRli (ORCPT ); Tue, 25 Jul 2023 13:41:38 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4531B1BE2 for ; Tue, 25 Jul 2023 10:41:36 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id d75a77b69052e-403ea0a50f7so44449071cf.1 for ; Tue, 25 Jul 2023 10:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; t=1690306895; x=1690911695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WJvVodEb8nnJEl20cUTyJdImyktiXScfem+69qgqo3Q=; b=e5ID1UqXliZ+Zyl9RyCsKE4cEfBV1Yk3CrsZNrSv5V3zn6E8LT99TL1D17Nwe6Lqiv nW/9bnXAFTLNnHj1mEGcktsTtyeTL09GQF65dj1XCRs8uhbyeGqbtPrqeu2zjjCtPw6E CGqFZ4KvpaNSKdpjWcT/8chMGtdRtPBD4m7d8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690306895; x=1690911695; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WJvVodEb8nnJEl20cUTyJdImyktiXScfem+69qgqo3Q=; b=NrBqpBgoZpOy0HzM31hCvHIwUiI+EdUwcLkGWfWKuzBBUIqUKjWdZRbSqKVqSHvY/o q4PlLOPwtE5twM8K+D+uERK03Dzi7ehE0kE7xWHk/JcHA/xAnQFC1+O71+CbRYAUHduR 9M7FC7xeeLrFUdzGQ9sv0xZPdK+jtYY1Vsqr4bXhTgozoBEgvgCHbKotNUOfRHkLW83w +b4lBpnMot/fFEKG6DzL0PHramZtZdyks2a6ntq/WkQIyq3Ha9dkuOrtQctWEGuP9DSO SZoFA+cPGRdi/n37qDZkEu8bKwsB2Ypk76tCeYgRh6ZzcwonBdesOvErMHzvfodAhO4Z wyYQ== X-Gm-Message-State: ABy/qLZVgAssjgpywKMY3tqBiVz2vv/UqtQtBMsHUhiR12MzXn5g6h6e f4tbCJKxYci29BVSIBjllvqoLg== X-Received: by 2002:a05:622a:1742:b0:403:b6a9:b8f9 with SMTP id l2-20020a05622a174200b00403b6a9b8f9mr3981171qtk.36.1690306895263; Tue, 25 Jul 2023 10:41:35 -0700 (PDT) Received: from [192.168.0.198] (c-98-249-43-138.hsd1.va.comcast.net. [98.249.43.138]) by smtp.gmail.com with ESMTPSA id z4-20020a05622a124400b004054b7cc490sm3480130qtx.73.2023.07.25.10.41.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 25 Jul 2023 10:41:34 -0700 (PDT) Message-ID: <1e254a35-d0c2-8d41-f020-21694945911a@joelfernandes.org> Date: Tue, 25 Jul 2023 13:41:32 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC PATCH v2 18/20] context_tracking,x86: Defer kernel text patching IPIs Content-Language: en-US To: Valentin Schneider Cc: linux-kernel@vger.kernel.org, linux-trace-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, Peter Zijlstra , Nicolas Saenz Julienne , 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 , 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 , =?UTF-8?Q?Thomas_Wei=c3=9fschuh?= , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Yair Podemsky References: <20230720163056.2564824-19-vschneid@redhat.com> <6EBAEEED-6F38-472D-BA31-9C61179EFA2F@joelfernandes.org> From: Joel Fernandes In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/25/23 09:36, Valentin Schneider wrote: > On 25/07/23 06:49, Joel Fernandes wrote: >> Interesting series Valentin. Some high-level question/comments on this one: >> >>> On Jul 20, 2023, at 12:34 PM, Valentin Schneider wrote: >>> >>> text_poke_bp_batch() sends IPIs to all online CPUs to synchronize >>> them vs the newly patched instruction. CPUs that are executing in userspace >>> do not need this synchronization to happen immediately, and this is >>> actually harmful interference for NOHZ_FULL CPUs. >> >> Does the amount of harm not correspond to practical frequency of text_poke? >> How often does instruction patching really happen? If it is very infrequent >> then I am not sure if it is that harmful. >> > > Being pushed over a latency threshold *once* is enough to impact the > latency evaluation of your given system/application. > > It's mainly about shielding the isolated, NOHZ_FULL CPUs from whatever the > housekeeping CPUs may be up to (flipping static keys, loading kprobes, > using ftrace...) - frequency of the interference isn't such a big part of > the reasoning. Makes sense. >>> As the synchronization IPIs are sent using a blocking call, returning from >>> text_poke_bp_batch() implies all CPUs will observe the patched >>> instruction(s), and this should be preserved even if the IPI is deferred. >>> In other words, to safely defer this synchronization, any kernel >>> instruction leading to the execution of the deferred instruction >>> sync (ct_work_flush()) must *not* be mutable (patchable) at runtime. >> >> If it is not infrequent, then are you handling the case where userland >> spends multiple seconds before entering the kernel, and all this while >> the blocking call waits? Perhaps in such situation you want the real IPI >> to be sent out instead of the deferred one? >> > > The blocking call only waits for CPUs for which it queued a CSD. Deferred > calls do not queue a CSD thus do not impact the waiting at all. See > smp_call_function_many_cond(). Ah I see you are using on_each_cpu_cond(). I should have gone through the other patch before making noise. thanks, - Joel