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 4880EC02198 for ; Wed, 12 Feb 2025 10:38:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69120280004; Wed, 12 Feb 2025 05:38:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 64110280002; Wed, 12 Feb 2025 05:38:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 508B7280004; Wed, 12 Feb 2025 05:38:53 -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 2D195280002 for ; Wed, 12 Feb 2025 05:38:53 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A96161A1835 for ; Wed, 12 Feb 2025 10:38:52 +0000 (UTC) X-FDA: 83110944504.29.B2F1B77 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf28.hostedemail.com (Postfix) with ESMTP id D493BC0007 for ; Wed, 12 Feb 2025 10:38:50 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tutetHcB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739356730; a=rsa-sha256; cv=none; b=RHrPbW9B0MUfS55TI6NhstcsLL5dacX8qbxjLD/NICmUisGrqSznoiZ8tdIqFykL9BIUxz e0SLcEdCA7FZLpB8a6n1yGmxpWJFCAa49/Tyjk2r0O5F0ZFk9vAjPRw/vbrVtfZgM5YITa rtfU4GKLwhSH9xspN6uvw9vikpVdMxU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=tutetHcB; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of jackmanb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=jackmanb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739356730; 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=SZypuT5krcMP4SFZDITfjouL/pSMfKVuh0e51cR4PXw=; b=vSQEzlXuDUZd32MlzHvlXM7ZuowHoOMYfw7EDb3Ocr/HaFP2fWUnaLftEuicrMjrYtluuA hicedVexLu/HriE1a9iMKcnJwi+TuFgbEU8DJaVEV932BNR6jYsmNypwThReiHSGM5jEGN 74IByiYWkDikHtTMU/SUwTiXugcBRF4= Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-47190a013d4so164781cf.1 for ; Wed, 12 Feb 2025 02:38:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1739356730; x=1739961530; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SZypuT5krcMP4SFZDITfjouL/pSMfKVuh0e51cR4PXw=; b=tutetHcB10SiGe2w26VSS3RcoTsvBfzQNK/ZrgxPXNWdv2nMR1ZDyy8vuc87stCCqo TuzR6T1MoW0SeURaVWJnbx0QOhi7QH3ox3jH1eppUD3HzCRp3xyWs95xg1eHtYD5U5kf lq1tEvFDWYOVaCy0aY2+em1qSjJvgOipMm+afT0sIZ8QOaXJ9N+dD8xNi8fldK7taMgI 2Irz6xxE3Qk5OSimbbCbSR5B2MPG4n95P/GCML/Psfw2bPRb3K3X9/ol2Zy/BuSDZ2gD dUeFQlWgVboFugXLhc+5WTMtob4etfMkC6CBXLeqdnfFwmQhzYDjHl6IQkIxLiNhEXbZ OzZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739356730; x=1739961530; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=SZypuT5krcMP4SFZDITfjouL/pSMfKVuh0e51cR4PXw=; b=PJJmQBsObYhl2LLIza7D+RZoGEanWI3FqUa1IIZiLfPdD9qq0e8SEGKTWrM/IVlLXv gc32HoSOkS0kvjjRo1uku2bIRwmy/+yJk0dbgSqdCB2DWmHEdL+0ggAhL8UrOH/zcpmG Y5UegR0f1MnuLmM8BCUcPGEbUYGURzZqgLf+VrNMbViaPqspAp9cYNdFAmvZoA+z4uLk C/BTtVEztBKc8of6fMkL8U70HbT2l05Fnc86YMYd71M+wJPSHZ3opMGMfi9vS+7ef/Gv Tk5DKfvo3ECkFZ1p7g8H9OUhFbqxWUPt2yTLwbe4r+JTWO0TFAmVbcBHDCorW1lNC+gY hiQA== X-Forwarded-Encrypted: i=1; AJvYcCU3wXbpg2hyKq6LQvG+dj7oP6xn22YII65hvmaVRsvwle9nfi1YRFKtjXXG0zXQMO4yPjkA1b8UxQ==@kvack.org X-Gm-Message-State: AOJu0Yy4Nn6/Xawr+VpYugyo0FTN8Z097u385MflFhgNRU85VR8bGOoj aSXqLRL/HPUqJcrDdnsQIITljFZ3lRMmFEhqhu3j6WRlwow3epr3L6anBOYr87NmjKvGCILojnR GdBnZMZstNK7bTpDVEQsVxQAf8o6YKNXjZB4D X-Gm-Gg: ASbGncuUeBawYm9GpH2G8YaT1orW9fWujHPuTRHfZXdgXVIh6mffTGXtb7zubPkqiz2 dwh+0R0g8dh2YFeTnwFzwcxymEIjIgJyYrexbOi+xSzm5mWsubhVk0xn+hecLEcAqs7GWOiO6K5 7CSvQk/9L/sUpavauHa3lt+IiyfRY= X-Google-Smtp-Source: AGHT+IElrirA3T7jJtl/cF/qJPO6MJFdNGdFKOFef6rccKK84LMIwNutRdXvIl2RlySmjN1aEpZkNiDKbr1f4jbgcCo= X-Received: by 2002:a05:622a:59c5:b0:466:8c7c:3663 with SMTP id d75a77b69052e-471b1c02099mr2335441cf.5.1739356729767; Wed, 12 Feb 2025 02:38:49 -0800 (PST) MIME-Version: 1.0 References: <20250206044346.3810242-1-riel@surriel.com> <20250206044346.3810242-11-riel@surriel.com> <2d20c333400b890f4983cf799576435abf1d8824.camel@surriel.com> In-Reply-To: From: Brendan Jackman Date: Wed, 12 Feb 2025 11:38:38 +0100 X-Gm-Features: AWEUYZnnptWZviVi5t3DfNQp_oZ7iOddvpSL765Hw78lYEAmJd91yLLtDHAOK_E Message-ID: Subject: Re: [PATCH v9 10/12] x86/mm: do targeted broadcast flushing from tlbbatch code To: Rik van Riel Cc: x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de, peterz@infradead.org, dave.hansen@linux.intel.com, zhengqi.arch@bytedance.com, nadav.amit@gmail.com, thomas.lendacky@amd.com, kernel-team@meta.com, linux-mm@kvack.org, akpm@linux-foundation.org, jannh@google.com, mhklinux@outlook.com, andrew.cooper3@citrix.com, Manali Shukla Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D493BC0007 X-Stat-Signature: yfwmgua9gmkw7yd3tywk7a8wk1hubir9 X-Rspam-User: X-HE-Tag: 1739356730-451007 X-HE-Meta: U2FsdGVkX1/5LLVO8oFUhfN1lN5la+o1N+NmMnwsZi66oeuOJ+BdZ5ybVvECbEqh9gNzhn4+DQYw83qfj0IzVMQKRV55W5SKAx6eI7z0HX905i+Ai0xUSrGCq1rT5Bjb9JVAsNeY18TNUBlQdgL0Lq2eW4j5yrORlmd8QEIqWZIbzQ/tt5mnwFkANxQnsNovKf65OtDlSEl5hWWftxTZOWj4ndRh9a4WmfdOmd4ZmtKPpXvUsxveL4aJLv9jivGosP+rpAgIBpCGzNa4Z3nmg5RHQMK1WZ5ovk2kfEh66ywBnWIiIM11NDhx3tSfR35UNDa44sNamHmKCVa3KJXEmXvQvMtTjb2wqQygOrwYWRGUVq1egA3KIDbnESBMzITJ9bAHD1Gdj2dBys6Q6g1xoy4JKHyyNHlA9fg6UyTLS/4qLg5+ThNQel+lID8kSk4VqEBcniBpAf3AVLHOxhagxIzSdKaQHa4RNxaG7URZByg0WbQNrRglg5EpmCyKyqGxmIXi/Sn4YXyAu586tqCFgCykAj7Jx9sQxagvyZpLVrZYuZe/Vkj2QBmGXE9RkREnJUKLTlEWSB3sCnswJaKBP59JeTTJIbvNqMw+7GD1uLOWqVK8Dxvh3Wh9iVBz/cA6pAPQ7X0RFEkGkwNN/hJCsDWnp+iryOcoPV6CHweCu8LKE9XJj3G8d+mF+8yJKCfzxSyiTXDSSs2AkfJODodaOfkAJhX+IAp2vh5EnVzRZESlWP1baBKIOkpjxM8Rba30inYVTJTnwSBLF/Lx6435PUWQ4nUVEKxbWFNoQ0iEF4Ufvd816r/OT/sD51mk23HM7pdtsYyyu7wh9Pj4OUaM5fyov/jlaRtVAZfL5fYSEs85cPyEuX+dU+AnGwEo9clyF2H+KYTNaZgWRDKk0C1aabxvgjyyhbYHKlBET6hVmscc6rMGcZ4Tc7d5WApY4c3bmvm2xf2qAEY6s2Elxnu m42Ktsb0 40ov3jr4jzxUdAhwGL+N36sTbszJLzaG2mg9H+JEH5C0yEqEqnnKoaV44DG9b6VlKRar7emLR2p729TVCSE0ib+Q5OZWH2C8er3q2fteBZW08BHxAErYVxdxoc+B+RaotzO8CRZHIMZgHC7nMQfSLcFWxWgdAY4lOH75SONe0nJsBw6vE9Kd9MOAYYj8dXMmef7BpiCwsihWKxThYCB9OoD2xxF+cmQ3/P/Q2mqwR7i6neGx4+AXHoujRrnQ6K19hXDH2xMhVu2XLm1Pc+tCvgmsc6OE/7FWHLSRVCWd80kM0uIieZeIB7F/alQjd/l1hj01loeHZkVEGJ3I= X-Bogosity: Ham, tests=bogofilter, spamicity=0.007813, 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 Tue, 11 Feb 2025 at 21:21, Rik van Riel wrote: > > On Tue, 2025-02-11 at 11:02 +0100, Brendan Jackman wrote: > > > > So I think here we're encoding the assumption that context_switch() > > always calls either enter_lazy_tlb() or switch_mm_irqs_off(), which > > is > > a little awkward, plus the job of these functions is already kinda > > hazy and this makes it even hazier. What about doing it in > > arch_start_context_switch() instead? > > > > That would mean a bit of plumbing since we'd still wanna have the > > tlbsync() in tlb.c, but that seems worth it to me. Plus, having it in > > one place would give us a spot to add a comment. Now that you point > > it > > out it does indeed seem obvious but it didn't seem so yesterday. > > > While that would be a little bit cleaner to maintain, > in theory, I'm not convinced that adding an extra > function call to the context switch path is worthwhile > for that small maintenance benefit. I don't see why it has to introduce a function call, can't we just have something like: static inline void arch_start_context_switch(struct task_struct *prev) { arch_paravirt_start_context_switch(prev); tlb_start_context_switch(prev); } The paravirt one would disappear when !CONFIG_PARAVIRT (as the current arch_start_context_switch() does) and the tlb one would disappear when !CONFIG_X86_BROADCAST_TLB_FLUSH. The whole thing should be inlinable.