linux-kernel - Re: [tip:x86/mm] [x86/mm/tlb] 209954cbc7: will-it-scale.per_thread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8c6ace22-38d7-4178-ae55-9a9cdcd981d9@intel.com>
Date: Mon, 2 Dec 2024 08:50:02 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Peter Zijlstra <peterz@...radead.org>, Rik van Riel <riel@...riel.com>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev,
 lkp@...el.com, linux-kernel@...r.kernel.org, x86@...nel.org,
 Ingo Molnar <mingo@...nel.org>,
 Linus Torvalds <torvalds@...ux-foundation.org>, Mel Gorman <mgorman@...e.de>
Subject: Re: [tip:x86/mm] [x86/mm/tlb] 209954cbc7:
 will-it-scale.per_thread_ops 13.2% regression

On 11/28/24 11:46, Mathieu Desnoyers wrote:
> AFAIU, this commit changes the way TLB flushes are inhibited when
> context switching away from a mm. This means that one additional TLB
> flush is performed to a given CPU even after it has context switched
> away from the mm, and only then is the mm_cpumask cleared for that CPU.
> 
> This could result in additional TLB flush IPI overhead in specific
> scenarios where the IPIs are typically triggered after a thread has
> context-switched out.

I can see how that might generally be a problem, but for this particular
workload:

> https://github.com/antonblanchard/will-it-scale/blob/master/tests/tlb_flush2.c

I'm not sure how it would apply.

will-it-scale should create one big process that runs for quite a long
while and is bound to one CPU. The threads can get scheduled out as
other things run, but they should pop right back on to the CPU.

There shouldn't be a lot of context switching in this workload.

It would be great if someone could reproduce this and double-check that
the theory about what's making it regress is really holding in practice.