[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmh8qr0p784.mognet@vschneid-thinkpadt14sgen2i.remote.csb>
Date: Fri, 24 Jan 2025 16:22:19 +0100
From: Valentin Schneider <vschneid@...hat.com>
To: Uladzislau Rezki <urezki@...il.com>
Cc: Uladzislau Rezki <urezki@...il.com>, Jann Horn <jannh@...gle.com>,
linux-kernel@...r.kernel.org, x86@...nel.org,
virtualization@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
loongarch@...ts.linux.dev, linux-riscv@...ts.infradead.org,
linux-perf-users@...r.kernel.org, xen-devel@...ts.xenproject.org,
kvm@...r.kernel.org, linux-arch@...r.kernel.org, rcu@...r.kernel.org,
linux-hardening@...r.kernel.org, linux-mm@...ck.org,
linux-kselftest@...r.kernel.org, bpf@...r.kernel.org,
bcm-kernel-feedback-list@...adcom.com, Juergen Gross <jgross@...e.com>,
Ajay Kaher <ajay.kaher@...adcom.com>, Alexey Makhalov
<alexey.amakhalov@...adcom.com>, Russell King <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Huacai Chen <chenhuacai@...nel.org>, WANG Xuerui <kernel@...0n.name>, Paul
Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, Dave
Hansen <dave.hansen@...ux.intel.com>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>, Arnaldo Carvalho de Melo
<acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Mark Rutland
<mark.rutland@....com>, Alexander Shishkin
<alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>, Ian
Rogers <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>, Boris Ostrovsky
<boris.ostrovsky@...cle.com>, Josh Poimboeuf <jpoimboe@...nel.org>, Pawan
Gupta <pawan.kumar.gupta@...ux.intel.com>, Sean Christopherson
<seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, Andy Lutomirski
<luto@...nel.org>, Arnd Bergmann <arnd@...db.de>, Frederic Weisbecker
<frederic@...nel.org>, "Paul E. McKenney" <paulmck@...nel.org>, Jason
Baron <jbaron@...mai.com>, Steven Rostedt <rostedt@...dmis.org>, Ard
Biesheuvel <ardb@...nel.org>, Neeraj Upadhyay
<neeraj.upadhyay@...nel.org>, Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Lai Jiangshan
<jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>, Juri Lelli
<juri.lelli@...hat.com>, Clark Williams <williams@...hat.com>, Yair
Podemsky <ypodemsk@...hat.com>, Tomas Glozar <tglozar@...hat.com>, Vincent
Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann
<dietmar.eggemann@....com>, Ben Segall <bsegall@...gle.com>, Mel Gorman
<mgorman@...e.de>, Kees Cook <kees@...nel.org>, Andrew Morton
<akpm@...ux-foundation.org>, Christoph Hellwig <hch@...radead.org>, Shuah
Khan <shuah@...nel.org>, Sami Tolvanen <samitolvanen@...gle.com>, Miguel
Ojeda <ojeda@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, "Mike
Rapoport (Microsoft)" <rppt@...nel.org>, Samuel Holland
<samuel.holland@...ive.com>, Rong Xu <xur@...gle.com>, Nicolas Saenz
Julienne <nsaenzju@...hat.com>, Geert Uytterhoeven <geert@...ux-m68k.org>,
Yosry Ahmed <yosryahmed@...gle.com>, "Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>, "Masami Hiramatsu (Google)"
<mhiramat@...nel.org>, Jinghao Jia <jinghao7@...inois.edu>, Luis
Chamberlain <mcgrof@...nel.org>, Randy Dunlap <rdunlap@...radead.org>,
Tiezhu Yang <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer
flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
On 21/01/25 18:00, Uladzislau Rezki wrote:
>> >
>> > 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.
>
Potentially as much as you want... In our Openshift environments, you can
get any sort of container executing on the housekeeping CPUs and they're
free to do pretty much whatever they want. Per CPU isolation they're not
allowed/meant to disturb isolated CPUs, however.
> Apart of that how critical IPIing CPUs affect your workloads?
>
If I'm being pedantic, a single IPI to an isolated CPU breaks the
isolation. If we can't quiesce IPIs to isolated CPUs, then we can't
guarantee that whatever is running on the isolated CPUs is actually
isolated / shielded from third party interference.
Powered by blists - more mailing lists