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 03D59C02182 for ; Tue, 21 Jan 2025 17:00:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 475F26B007B; Tue, 21 Jan 2025 12:00:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FF8D6B0082; Tue, 21 Jan 2025 12:00:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 22ABD6B0083; Tue, 21 Jan 2025 12:00:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 059EB6B007B for ; Tue, 21 Jan 2025 12:00:18 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8233A120D83 for ; Tue, 21 Jan 2025 17:00:18 +0000 (UTC) X-FDA: 83032072116.15.99331B8 Received: from mail-lf1-f47.google.com (mail-lf1-f47.google.com [209.85.167.47]) by imf15.hostedemail.com (Postfix) with ESMTP id 53E52A0004 for ; Tue, 21 Jan 2025 17:00:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="B2Ia/HbD"; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737478816; 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=6O7kZyVX02YaNVvlK+AnjIGslDTljYFtI1mm3L3G+es=; b=gAdneo7hMRIV/KetQT2XkqXVn66ItfCaXEuIUe8g1P1WqdWNNtA+Krtutt/CTg1uDPerfQ m50I22dV+BUnbEbnWFkjCrvxejDCUvELxdQMjYdsMOBuZoRmixBOlZyINIFgKmWoYKA21J 5pqpAzUa2ykphXxVy3LPztCU6eHxVIo= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="B2Ia/HbD"; spf=pass (imf15.hostedemail.com: domain of urezki@gmail.com designates 209.85.167.47 as permitted sender) smtp.mailfrom=urezki@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737478816; a=rsa-sha256; cv=none; b=v1kl00ZxD7Vz9n1l50Q/MvNIkZ+XEYkMbWwKbg16d8ffbbpvxPCKdQg7BglLILXswMwYWu uUfUvJKtJcuPqm0T9/VU0CotlhajCvCcDbl38YXyS81DMzqzURlopnfu9Kd5NcjWC9hZa5 wEYxskaVLmMK78lgh06j39SD8REEsTk= Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-53f22fd6832so6170903e87.1 for ; Tue, 21 Jan 2025 09:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737478814; x=1738083614; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=6O7kZyVX02YaNVvlK+AnjIGslDTljYFtI1mm3L3G+es=; b=B2Ia/HbDSWrHG7ylR8jQmBqxfxs+OJf5eq8ZuApbf04/L1VhNXWxWQjgqPyR8MjDLx P+S+Quj3U6BJwXJlPik0fcvl23sZeAI1bOAfjcmqMmxToVYUFZ7MI9HiH66CBbsE90qA rS74KMyLC372nRk01nPBvRWIokFnXzo1MoiF5W8wC6skA1gm9fimy/CJWsDXlZ+F4XOq oVlSEEOvMVF3PCHq3Mfv3tRC4hZQRfs8UAGw3nDNhrzd5RymT75WGbkRvCSueBWsv5V7 vlaLkQHycMo9eOZHa8tkyfLrFd7uWPaJmB3BFi9/tWlb4qLlnIXVg3ZRh8i0V/s73kKw I63A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737478814; x=1738083614; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6O7kZyVX02YaNVvlK+AnjIGslDTljYFtI1mm3L3G+es=; b=utOHAJthGJJwanMHlUSI9Q9Zm2+VrC4eONc56XD2uiSXeXyMDGEVgBksrxNYiWK/aV VO7iBAw7xFM/b2OYM39Vqqlzdox5GVjvjgxkMfB0G66MY+aX/fI9kPxwdCI/bhHnBNbL SwA2l+/MDzvdGRopnkJA71UgPEEPdpoGHXSMVw4x7ZijJn4VxURh8aCBLpdShftXrw83 qnv8I6VDP4MDcI+WDcLPZFkOIHjQiOSodget1uMZkEov5iFm1zTcypQXisFC3P7oln/Z /waey8PEyZB81sbhzIYKVL6bX3PJIDtYVLzoo2clnuytZF4+/A1BPvy1K6LcijzHmYfM tjwQ== X-Forwarded-Encrypted: i=1; AJvYcCUu7Z2kFAr3/c7xkRAf2r0JLV+kMg/NKPaaK7IjWJsrkDFXUW6EQyFv7z9kBkvtFjnI72UdVhNdQw==@kvack.org X-Gm-Message-State: AOJu0YwW2hzfs+rSp2aOPS0DKY59gMvbYSADzhLu9VQJL1EYiRJk6cyO IcP1eZOsbg3pYShUnSxjggrAuW9at9XpD2mYMJVkVQHsmJCIVQGd X-Gm-Gg: ASbGncvJrzB7YqfNcmGF5bf+kXp+tDottRPD7L62Qqeq8lggDzjgv1yFmdg1LK96MPT lYFeA/auSgyGcaY73l/bJF85X29Q0NWwAfsnS4RX1RojcCwaLKi6VWPjQxOu55i7fTiWGh+4+RZ b1WXsNyih4n9Gcw/yFNnYZrws3RkKPTyTsxzwEMEhnW0bv0uHDfiK1ELEhozqUftByMrTpvj1CQ q1Imu0PdJcdlHKeZxYhQsr2r+QSjT/ZeuwLgg6pWe94Bz6HP/ScsnSfKU0mo2uqBlaPfCi+VCrK XDowfbCY35OJS+44rtkJjQ1v X-Google-Smtp-Source: AGHT+IGYPF71D1RmaKnbW82c+U5IMmpDPZJTk/HJCRRaq5z7S90tH0rTVzhA6Sl8Kwc0O/33Vf8jgg== X-Received: by 2002:a05:6512:104b:b0:543:9b0f:7d39 with SMTP id 2adb3069b0e04-5439c282920mr7151519e87.32.1737478813837; Tue, 21 Jan 2025 09:00:13 -0800 (PST) Received: from pc636 (host-217-213-93-172.mobileonline.telia.com. [217.213.93.172]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5439af76fe9sm1916768e87.212.2025.01.21.09.00.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 21 Jan 2025 09:00:12 -0800 (PST) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Tue, 21 Jan 2025 18:00:07 +0100 To: Valentin Schneider Cc: Uladzislau Rezki , Jann Horn , linux-kernel@vger.kernel.org, x86@kernel.org, virtualization@lists.linux.dev, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-riscv@lists.infradead.org, linux-perf-users@vger.kernel.org, xen-devel@lists.xenproject.org, kvm@vger.kernel.org, linux-arch@vger.kernel.org, rcu@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, bpf@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, Juergen Gross , Ajay Kaher , Alexey Makhalov , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Paul Walmsley , Palmer Dabbelt , Albert Ou , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Peter Zijlstra , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , "Liang, Kan" , Boris Ostrovsky , Josh Poimboeuf , Pawan Gupta , Sean Christopherson , Paolo Bonzini , Andy Lutomirski , Arnd Bergmann , Frederic Weisbecker , "Paul E. McKenney" , Jason Baron , Steven Rostedt , Ard Biesheuvel , Neeraj Upadhyay , Joel Fernandes , Josh Triplett , Boqun Feng , Mathieu Desnoyers , Lai Jiangshan , Zqiang , Juri Lelli , Clark Williams , Yair Podemsky , Tomas Glozar , Vincent Guittot , Dietmar Eggemann , Ben Segall , Mel Gorman , Kees Cook , Andrew Morton , Christoph Hellwig , Shuah Khan , Sami Tolvanen , Miguel Ojeda , Alice Ryhl , "Mike Rapoport (Microsoft)" , Samuel Holland , Rong Xu , Nicolas Saenz Julienne , Geert Uytterhoeven , Yosry Ahmed , "Kirill A. Shutemov" , "Masami Hiramatsu (Google)" , Jinghao Jia , Luis Chamberlain , Randy Dunlap , Tiezhu Yang Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs Message-ID: References: <20250114175143.81438-1-vschneid@redhat.com> <20250114175143.81438-30-vschneid@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 53E52A0004 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: p4y5rogqy6i9f8doebn1kxe8in1bhyjn X-HE-Tag: 1737478816-651297 X-HE-Meta: U2FsdGVkX19WyRvlC+qhvXKLcRI4ObSQ9TpCemejN5dJMLo4AyFGTjcU10cnWBosRjg/79rxkPh6xpoRUqeOyqxsIduwQ/WhIW9M+iQxGnOgloHOJ0uoupgtDdbBkwBP33nCAQmkoxK3eEZ+Vb95KqHhMB7N5H+nkHKWZixhRTY0DdRSY2kjNoVzGKYrPgKuH96Uh05yFnmOGQpA8qMToaZ2YEmJDmIdvZkSgE95QPYohzPg93olcMhaeLPJBg70nuVP4+zOJKfqD+mhDn2VMCw7LLqok+hJvfpPog4W3+V0Csa8NR0+a6Q4Al+70PsyrIlY0cjs7JaXGfKkHOp1l9bOYVIpvPz9OuxFB66E6tOV7DsKXoGwJz6gaW1ZgMpVXJZAtOlBZNb5iXinT65AI2Xr6RSH5Ouz3WENEOUhxKrNUH4+wUsdnVmDh1cFPXrOtZ/bWYjmPRI2M1V91xAL1ShZ9p/jPFcX3fItpAiUaGNf0WFkW5UfxoWkVdgoT1vanCnC/6ObS+ZimZQunEaLd1ouoGOZ6vQHeMTeUvELC3io63MGgNEy4kU+sVQfV6akgOVfEgX/ejAg3Iq91LwBIvSZXiZTE8GbPVoZ0RBSezjITwZrkjZ9TQd+ESed/4/veVelyAr4O/+9M4cWgxbV2hcpPt2FWj+Hx89SXteg6VAuZzOktj1EHGS7U80UzBfOcDHaNKqXTTL/c9Q5M9a+/hfoWEK5ytE72wDTPaPbsLWs06acBrktkfTFNOpHMeizvHXDFMJUTkjacZRIITUrtFiT9VpZc13cbIEXSOnJme2KHQ3GjWJkVz6bUtd2noTyeCvCcaVU+xc14nHB+9IieKOud0Ld37wW+yrC8mHmgooj0/adL/e5do3mFEUTIa15MtmfbKJ920fUGZjofN++wOcZwqNf27VGy9pJY9kIHRf31ILqKEP24rgWqtB5wWeSlvfdfwyTyGsQ6/IWi17 ++JZr0C5 XhIYIvxNsnl03RW79y+3qNiNRefcnuVxO6/uGpAJDtBTFld3Oba4LDG0urru9UhzmXsZiYDGu4M06h1DsoQe+v2oj2H9lfoMcg3GdsaYcbl17TDYgb2l1WJk508+ATx/RnJ0Jm63E4cEc/aWENgtJtKHm3y7P6dq/xJdjwfeW3ZLprfzvxtgP3bFrXno4L+S0mOBZKsW7afbf5skinQQKtNxHMiIoBDPOae16ZDVt0Vev1R+EBEF5RMONC+DawyEvxW73Y8DT0o3YyE4v1V1n4OyHQvNQueJKBqg1p88mOqbniUvxUFrpX7CKyQYXZCOoDBizT6EaRIDNcjLrwnT+KVllgGnxZiyAs9JLuh92kcNVafuBtsXIF+ZJlS9dB1vn1+bzCUpHJc5eqj70NMVKu+WX4FlCS7Pq2lPqEXsFbFZRqxfj9dIylrNUA9doqe733DYJGGlTpsnFpqA0DUwE3orew1llyXBYFU9lQ2s1jj5eEWYCnAGW0qPuufauRjpQ8IdF5OKa1KdXtSc= 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: > > > > As noted before, we defer flushing for vmalloc. We have a lazy-threshold > > which can be exposed(if you need it) over sysfs for tuning. So, we can add it. > > > > In a CPU isolation / NOHZ_FULL context, isolated CPUs will be running a > single userspace application that will never enter the kernel, unless > forced to by some interference (e.g. IPI sent from a housekeeping CPU). > > Increasing the lazy threshold would unfortunately only delay the > interference - housekeeping CPUs are free to run whatever, and so they will > eventually cause the lazy threshold to be hit and IPI all the CPUs, > including the isolated/NOHZ_FULL ones. > Do you have any testing results for your workload? I mean how much potentially we can allocate. Again, maybe it is just enough to back and once per-hour offload it. Apart of that how critical IPIing CPUs affect your workloads? > I was thinking maybe we could subdivide the vmap space into two regions > with their own thresholds, but a task may allocate/vmap stuff while on a HK > CPU and be moved to an isolated CPU afterwards, and also I still don't have > any strong guarantee about what accesses an isolated CPU can do in its > early entry code :( > I agree this is not worth to play with a vmap space in terms of splitting it. Sorry for later answer and thank you! -- Uladzislau Rezki