[lkml]   [2018]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 4/7] x86,tlb: make lazy TLB mode lazier
[I added PeterZ and Vitaly -- can you see any way in which this would
break something obscure? I don't.]

On Thu, Jul 19, 2018 at 7:14 AM, Rik van Riel <> wrote:
> I guess we can skip both switch_ldt and load_mm_cr4 if real_prev equals
> next?


> On to the lazy TLB mm_struct refcounting stuff :)
>> Which refcount? mm_users shouldn’t be hot, so I assume you’re talking about
>> mm_count. My suggestion is to get rid of mm_count instead of trying to
>> optimize it.
> Do you have any suggestions on how? :)
> The TLB shootdown sent at __exit_mm time does not get rid of the
> kernelthread->active_mm
> pointer pointing at the mm that is exiting.

Ah, but that's conceptually very easy to fix. Add a #define like
ARCH_NO_TASK_ACTIVE_MM. Then just get rid of active_mm if that
#define is set. After some grepping, there are very few users. The
only nontrivial ones are the ones in kernel/ and mm/mmu_context.c that
are involved in the rather complicated dance of refcounting active_mm.
If that field goes away, it doesn't need to be refcounted. Instead, I
think the refcounting can get replaced with something like:

* Release any arch-internal references to mm. Only called when
mm_users is zero
* and all tasks using mm have either been switch_mm()'d away or have had
* enter_lazy_tlb() called.
extern void arch_shoot_down_dead_mm(struct mm_struct *mm);

which the kernel calls in __mmput() after tearing down all the page
tables. The body can be something like:

if (WARN_ON(cpumask_any_but(mm_cpumask(...), ...)) {
/* send an IPI. Maybe just call tlb_flush_remove_tables() */

(You'll also have to fix up the highly questionable users in
arch/x86/platform/efi/efi_64.c, but that's easy.)

Does all that make sense? Basically, as I understand it, the
expensive atomic ops you're seeing are all pointless because they're
enabling an optimization that hasn't actually worked for a long time,
if ever.

 \ /
  Last update: 2018-07-19 18:46    [W:0.147 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site