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 92621C0015E for ; Tue, 25 Jul 2023 13:37:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BB7C6B0074; Tue, 25 Jul 2023 09:37:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 143C16B0075; Tue, 25 Jul 2023 09:37:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EFF468D0001; Tue, 25 Jul 2023 09:37:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id DFA7D6B0074 for ; Tue, 25 Jul 2023 09:37:15 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A28AD1C9E33 for ; Tue, 25 Jul 2023 13:37:15 +0000 (UTC) X-FDA: 81050235630.02.4F89D52 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 8121040024 for ; Tue, 25 Jul 2023 13:37:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gnhZs+ah; spf=pass (imf11.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=1690292233; 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=eDdtOP85xg33Pcp/dWSfNuetVHqsDidnGvcRgt3shrs=; b=UfXKqHKXg9BPkkMsxa+lH1evqRtTHBbL12mIqQfbh9M8MuQco+R0OM/lzrA1kedY22BbEi M/w3o5rbcrxm700ZmIS+IMnZUe2Orjz3nSjtTNsxGzX361614BzN/41VRQXJZ56f4KZuUD F7If9vgBCU8t44ZusV6H/QU5P45x7Zg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gnhZs+ah; spf=pass (imf11.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=1690292233; a=rsa-sha256; cv=none; b=m5Cs96MigXx2mhYJaZW9bOfec99LoYtf82uLPSpHDZKTLICIppORelwqAjTbVBfH26vEOw kr7bRsY4BXRZ83hEA/HCwQyeuJmUuWffc+wE7A/DWabUHnHDkWOimtbYF+Z1kArVOeM4uw TUg29SA2sx3M4LOukEdBXmcVOcej43o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1690292232; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eDdtOP85xg33Pcp/dWSfNuetVHqsDidnGvcRgt3shrs=; b=gnhZs+ahMiI1hlfNUfe+xpQRg/SCGjhXM4BTAqIgoWa4U4ei+P31EwlIKbqnJGHtsVMk0C dLQlPhA21ncXjc04fdIgpVd3cxeQ7VodbnGHQXSB6Ul/vkG3P1HmLSC45kr/Ci5x2+WTb8 9IvTGquyrcTo0ZkrbSyW+SI0Wq9ftBY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-195-EXcwfBNIOyy41K9kWrrLvA-1; Tue, 25 Jul 2023 09:37:11 -0400 X-MC-Unique: EXcwfBNIOyy41K9kWrrLvA-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-2f2981b8364so3260360f8f.1 for ; Tue, 25 Jul 2023 06:37:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690292223; x=1690897023; h=content-transfer-encoding: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=YuHDDSh+hqntXfEBDTeZy9lkclJmyfPYzRYLt1ff+f8=; b=VWNqFjglbAxsWM8a4Q/TvCJTCOcZMcAre9Q8mofrIqt9t9se5tUNJi3QIiqTl7Ao/A xDVPrv/emdifQts4qewq+3qYu58el2gkzxL+4Sfm/n4U731pIpyoYX4p447UstsCnrp6 aGlpAPqy7SjQ3pS4aTNauyqrsu1kIpSx01gvIYHtQ9Z/R5kB0e1VZ23pcFR+tUrOWYEd OvQ96YLa9KDIClHu/9GIvHc3133KycBO4jqe/nXC6gYPZbllNBQgKEFF83Aqaxsh0rPl dvXukUQm1VlgA30ZeMqQ+I/U+/lMv+NI5SGGtg2uNuDgUK/dPzbLWnXePMTOFhKS5lIE KCXQ== X-Gm-Message-State: ABy/qLaPzZ7p7Re5mrtKnIAyy/ewdeZQgDK8WRxbwZeXGIgsMFJZ8EtK I0ocvg08LllBAUZLvMHZWxl/IyYuLdsr1TeUlA/JjyjAnX2kwVq3SUmSk48co377kX5bxNlDtF6 mjPSNTri7r/8= X-Received: by 2002:adf:edd1:0:b0:313:df09:ad04 with SMTP id v17-20020adfedd1000000b00313df09ad04mr11718225wro.57.1690292223002; Tue, 25 Jul 2023 06:37:03 -0700 (PDT) X-Google-Smtp-Source: APBJJlEu1q96uzpYLmrQ6ZyLxOIliHI6bjUjLVOksOKXP2KWpblMNlkbQak2J3cKJncV5JGWmoXhZA== X-Received: by 2002:adf:edd1:0:b0:313:df09:ad04 with SMTP id v17-20020adfedd1000000b00313df09ad04mr11718201wro.57.1690292222669; Tue, 25 Jul 2023 06:37:02 -0700 (PDT) Received: from vschneid.remote.csb ([149.12.7.81]) by smtp.gmail.com with ESMTPSA id h3-20020a5d4fc3000000b00314329f7d8asm16390715wrw.29.2023.07.25.06.36.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Jul 2023 06:37:01 -0700 (PDT) From: Valentin Schneider To: Joel Fernandes 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 , Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Juri Lelli , Daniel Bristot de Oliveira , Marcelo Tosatti , Yair Podemsky Subject: Re: [RFC PATCH v2 18/20] context_tracking,x86: Defer kernel text patching IPIs In-Reply-To: <6EBAEEED-6F38-472D-BA31-9C61179EFA2F@joelfernandes.org> References: <20230720163056.2564824-19-vschneid@redhat.com> <6EBAEEED-6F38-472D-BA31-9C61179EFA2F@joelfernandes.org> Date: Tue, 25 Jul 2023 14:36:59 +0100 Message-ID: MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8121040024 X-Rspam-User: X-Stat-Signature: da8gyjd768s13gk3b1kkz6c7it378pd3 X-Rspamd-Server: rspam01 X-HE-Tag: 1690292233-635774 X-HE-Meta: U2FsdGVkX18jVOeSrGqrAs7fIpQ5UiLDUBVyDaFwWn4m+4+9jF7veRF9wXRRtu2fLPidNFhMBK283VBk0p9lUEIpFJMJcXP59J6ro/yuLl3YqhQtutCNiCA9yExNgowyWnvqVGOPlV/bTqZI8MiiRxUCR4Wikk/aA5/mz2ZSClezTyfv5X8JWVkXX+34Q4WLkhUr3yY+Npul6i/CVdEDawiyASs5Rfh2CazPiK9TBdyFoZ+5TrR3FFIA3iV6hY1+yKOUR+728NrEqsRpsRaPMvZjoiWQ00TLCsKfroiVHyHo1zwKuv8ics+Vap0eZKJUFxDBlLSmpaqi1jxlmvTe52+36YIrIZxq8ZH1R8x0ehdUyKj+K1wU4k51zf1xSwBGj6dZbphehAj9IwHluu8IY/GJz+diQbTP7fZp5soZTAEsnhDVhbQwbXffTH/qRSHt9y1kp0WE4q7i4qG6xExJtFbYere/djMpf2nIdtDP6yLLqhm2ZmkUZ7BWJbUqCDYPSw7PatCwEw15AsIUW7nmbvIFQG+tu4Ove8rpfVxCW3PnQ/smRclHLTPxDDGyrY6h+5V0K1Bs29FtOBOXUJK0xR74u7uEiRJlKlQ26Z0bOdEvVEfqgvQ/uFegr/MuKWO3Gpexl6FYIoBkS5MKX4hRU+pUiFcrgNGrIiwxLR4kFY+s1i9iEywg90O8vfwiCJcMyXbQApFZLN1eWWZp7zA3rWJYi23fjspy9Dkzjz6HDJwOFoQ1lMOmVazIMqg8wXOOA2sD1qNSbW5HIDfuqMalHBvfqvOKffR7V+oDfLK72HWZzE5CBxwnLDn1jEpKuxL3eoogTqOcHiPW6opvb+HkJFQWZK5M+jvmK9Far3GyN+hOJbLy/HGcEug+Zm4gQQrZpBBahp+4n6pnc850Zl9PzMkvRYQBl9BWeGq62kOJd1ZAJq6PRzq1VVbho6I28KVijp/K1AStvHe1x3oec/Y 5Iegsj2R NZ+yWXwvIIeDdrQnxwbbXhZj/IeRnh6wdwIg2qYIrjvMW24EufMw9eE/gEjYQAPw1lPMxGWx+vXKeDkFHxuu3eFvYk1UM19sR7uRtwJN6cnKf4JT3JrQdvUsAX8xiwWRHt3eOAbfND/6gVH5QGF2K+FQg9q4E6zTc2wUqpkQjuvDt1Bs+vB9bbKM/PoiJuLNOxAnRkpJD4L09xWznxN8RRVAoKnCwZDouafYV1nn2qViiPEuutNZMmIauG0YGSombKTgamxlYVdX7L8ai3neAxcnrvP5Dn6FiqSX+vn4lUyCgY2L/mh210lADO/4dSYbegrwG5cDoM/Cq+503PlUrnQReGMhGkvzP7dDUt9dYB+/UN+y6uzvx3twvcZZaXQ42MVMDYTA96O6NuwBAPGSNHKzSFk0PjrscU9uh8BDhE2t5VP0= 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 25/07/23 06:49, Joel Fernandes wrote: > Interesting series Valentin. Some high-level question/comments on this on= e: > >> On Jul 20, 2023, at 12:34 PM, Valentin Schneider w= rote: >> >> =EF=BB=BFtext_poke_bp_batch() sends IPIs to all online CPUs to synchroni= ze >> them vs the newly patched instruction. CPUs that are executing in usersp= ace >> 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_pok= e? > How often does instruction patching really happen? If it is very infreque= nt > 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. >> >> As the synchronization IPIs are sent using a blocking call, returning fr= om >> 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().