[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs
- To: Uladzislau Rezki <urezki@xxxxxxxxx>
- From: Valentin Schneider <vschneid@xxxxxxxxxx>
- Date: Fri, 24 Jan 2025 16:22:19 +0100
- Cc: Uladzislau Rezki <urezki@xxxxxxxxx>, Jann Horn <jannh@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, x86@xxxxxxxxxx, virtualization@xxxxxxxxxxxxxxx, linux-arm-kernel@xxxxxxxxxxxxxxxxxxx, loongarch@xxxxxxxxxxxxxxx, linux-riscv@xxxxxxxxxxxxxxxxxxx, linux-perf-users@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, kvm@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, rcu@xxxxxxxxxxxxxxx, linux-hardening@xxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, linux-kselftest@xxxxxxxxxxxxxxx, bpf@xxxxxxxxxxxxxxx, bcm-kernel-feedback-list@xxxxxxxxxxxx, Juergen Gross <jgross@xxxxxxxx>, Ajay Kaher <ajay.kaher@xxxxxxxxxxxx>, Alexey Makhalov <alexey.amakhalov@xxxxxxxxxxxx>, Russell King <linux@xxxxxxxxxxxxxxx>, Catalin Marinas <catalin.marinas@xxxxxxx>, Will Deacon <will@xxxxxxxxxx>, Huacai Chen <chenhuacai@xxxxxxxxxx>, WANG Xuerui <kernel@xxxxxxxxxx>, Paul Walmsley <paul.walmsley@xxxxxxxxxx>, Palmer Dabbelt <palmer@xxxxxxxxxxx>, Albert Ou <aou@xxxxxxxxxxxxxxxxx>, Thomas Gleixner <tglx@xxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>, Namhyung Kim <namhyung@xxxxxxxxxx>, Mark Rutland <mark.rutland@xxxxxxx>, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx>, Jiri Olsa <jolsa@xxxxxxxxxx>, Ian Rogers <irogers@xxxxxxxxxx>, Adrian Hunter <adrian.hunter@xxxxxxxxx>, "Liang, Kan" <kan.liang@xxxxxxxxxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>, Josh Poimboeuf <jpoimboe@xxxxxxxxxx>, Pawan Gupta <pawan.kumar.gupta@xxxxxxxxxxxxxxx>, Sean Christopherson <seanjc@xxxxxxxxxx>, Paolo Bonzini <pbonzini@xxxxxxxxxx>, Andy Lutomirski <luto@xxxxxxxxxx>, Arnd Bergmann <arnd@xxxxxxxx>, Frederic Weisbecker <frederic@xxxxxxxxxx>, "Paul E. McKenney" <paulmck@xxxxxxxxxx>, Jason Baron <jbaron@xxxxxxxxxx>, Steven Rostedt <rostedt@xxxxxxxxxxx>, Ard Biesheuvel <ardb@xxxxxxxxxx>, Neeraj Upadhyay <neeraj.upadhyay@xxxxxxxxxx>, Joel Fernandes <joel@xxxxxxxxxxxxxxxxx>, Josh Triplett <josh@xxxxxxxxxxxxxxxx>, Boqun Feng <boqun.feng@xxxxxxxxx>, Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>, Lai Jiangshan <jiangshanlai@xxxxxxxxx>, Zqiang <qiang.zhang1211@xxxxxxxxx>, Juri Lelli <juri.lelli@xxxxxxxxxx>, Clark Williams <williams@xxxxxxxxxx>, Yair Podemsky <ypodemsk@xxxxxxxxxx>, Tomas Glozar <tglozar@xxxxxxxxxx>, Vincent Guittot <vincent.guittot@xxxxxxxxxx>, Dietmar Eggemann <dietmar.eggemann@xxxxxxx>, Ben Segall <bsegall@xxxxxxxxxx>, Mel Gorman <mgorman@xxxxxxx>, Kees Cook <kees@xxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Shuah Khan <shuah@xxxxxxxxxx>, Sami Tolvanen <samitolvanen@xxxxxxxxxx>, Miguel Ojeda <ojeda@xxxxxxxxxx>, Alice Ryhl <aliceryhl@xxxxxxxxxx>, "Mike Rapoport (Microsoft)" <rppt@xxxxxxxxxx>, Samuel Holland <samuel.holland@xxxxxxxxxx>, Rong Xu <xur@xxxxxxxxxx>, Nicolas Saenz Julienne <nsaenzju@xxxxxxxxxx>, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx>, Yosry Ahmed <yosryahmed@xxxxxxxxxx>, "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>, "Masami Hiramatsu (Google)" <mhiramat@xxxxxxxxxx>, Jinghao Jia <jinghao7@xxxxxxxxxxxx>, Luis Chamberlain <mcgrof@xxxxxxxxxx>, Randy Dunlap <rdunlap@xxxxxxxxxxxxx>, Tiezhu Yang <yangtiezhu@xxxxxxxxxxx>
- Delivery-date: Fri, 24 Jan 2025 15:23:25 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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.
|