linux-kernel - Re: [PATCH] x86,mm: only trim the mm

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: <0669c39395c544bb57e1ccd21010ba53147126fb.camel@surriel.com>
Date: Wed, 04 Dec 2024 11:07:33 -0500
From: Rik van Riel <riel@...riel.com>
To: Oliver Sang <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org, 
	x86@...nel.org, Ingo Molnar <mingo@...nel.org>, Dave Hansen
 <dave.hansen@...el.com>,  Linus Torvalds <torvalds@...ux-foundation.org>,
 Peter Zijlstra <peterz@...radead.org>, Mel Gorman	 <mgorman@...e.de>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] x86,mm: only trim the mm_cpumask once a second

On Wed, 2024-12-04 at 21:15 +0800, Oliver Sang wrote:
> 
> we tested this patch, unfortunately, we found even bigger regression
> in our
> will-it-scale tests. and for another vm-scalability test, it also
> causes a
> little worse performance.
> 
> we noticed there is the v2 for this patch, not sure if any
> significant changes
> which could impact performance? if so, please notify us and we could
> test
> further. thanks
> 
> below is details.

Looking at the profile, it looks like:
1) switch_mm_irqs_off is somehow taking more
   CPU time after these changes, despite
   removing an unconditional atomic set_bit.
   I have no good explanation for this.
2) Moving some overhead from the fast path
   in the context switch patch (switch_mm_irqs_off)
   to the slower path in flush_tlb_func isn't
   right for the tlb_flush2 threaded test,
   which basically only does madvise and
   TLB flushes :)

However, I think we can reduce the overhead
in the TLB flush side a little more, by moving
the jiffies test from tlb_flush_func into the
calling unction flush_tlb_mm_range, so the
jiffies comparison is only ever done on the
calling CPU, not on all the CPUs that receive
the IPIs.

Let me send over a v3 in a little bit.