All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>, kernel-team <kernel-team@fb.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Mike Galbraith <efault@gmx.de>,
	songliubraving@fb.com
Subject: Re: [PATCH 3/6] x86,tlb: make lazy TLB mode lazier
Date: Thu, 28 Jun 2018 16:05:18 -0400	[thread overview]
Message-ID: <1530216318.16379.4.camel@surriel.com> (raw)
In-Reply-To: <CALCETrVgDXe6NFCmxhyiwMEQmQqyidAh+wQBWeaCKg+z6jQOPw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2347 bytes --]

On Wed, 2018-06-27 at 11:10 -0700, Andy Lutomirski wrote:
> 
> You left this comment:
> 
>                 /*
>                  * We don't currently support having a real mm loaded
> without
>                  * our cpu set in mm_cpumask().  We have all the
> bookkeeping
>                  * in place to figure out whether we would need to
> flush
>                  * if our cpu were cleared in mm_cpumask(), but we
> don't
>                  * currently use it.
>                  */
> 
> Presumably you should either clear the cpu from mm_cpumask when lazy
> or you shoudl update the comment.

The lazy TLB mode leaves the mm loaded, AND the
cpu set in mm_cpumask(). However, I guess while
the comment is technically accurate, it is no longer
relevant, so I will update it :)

> > +               /*
> > +                * Switching straight from one thread in a process
> > to another
> > +                * thread in the same process requires no TLB flush
> > at all.
> > +                */
> > +               if (!was_lazy)
> > +                       return;
> 
> Comment doesn't match code.  Maybe add "... if we weren't lazy"?

Done.

> > +
> > +               /*
> > +                * The code below checks whether there was a TLB
> > flush while
> > +                * this CPU was in lazy TLB mode. The barrier
> > ensures ordering
> > +                * with the TLB invalidation code advancing
> > .tlb_gen.
> > +                */
> > +               smp_rmb();
> 
> I think it may need to be smp_mb().  You're trying to order
> this_cpu_write() against subsequent reads.

I have updated the barrier to an smp_mb().

> In general, the changes to this function are very hard to review
> because you're mixing semantic changes and restructuring the
> function.
> Is there any way you could avoid that?  Or maybe just open-code a
> tlb_gen check in the unlazying path?
> 
> 
> > +       /*
> > +        * Instead of sending IPIs to CPUs in lazy TLB mode, move
> > that
> > +        * CPU's TLB state to TLBSTATE_FLUSH, causing the TLB to be
> > flushed
> > +        * at the next context switch, or at page table free time.
> > +        */
> 
> Stale comment?

Will fix.

I am running some last tests now, and will send
v3 soon.

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2018-06-28 20:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-26 17:31 [PATCH v2 0/7] x86,tlb,mm: make lazy TLB mode even lazier Rik van Riel
2018-06-26 17:31 ` [PATCH 1/6] mm: allocate mm_cpumask dynamically based on nr_cpu_ids Rik van Riel
2018-06-26 17:31 ` [PATCH 2/6] x86,tlb: leave lazy TLB mode at page table free time Rik van Riel
2018-06-27  6:03   ` kbuild test robot
2018-06-26 17:31 ` [PATCH 3/6] x86,tlb: make lazy TLB mode lazier Rik van Riel
2018-06-27 18:10   ` Andy Lutomirski
2018-06-27 18:17     ` Rik van Riel
2018-06-28 20:05     ` Rik van Riel [this message]
2018-06-26 17:31 ` [PATCH 4/6] x86,tlb: only send page table free TLB flush to lazy TLB CPUs Rik van Riel
2018-06-26 20:16   ` [RFC PATCH] x86,tlb: mm_fill_lazy_tlb_cpu_mask() can be static kbuild test robot
2018-06-26 20:16   ` [PATCH 4/6] x86,tlb: only send page table free TLB flush to lazy TLB CPUs kbuild test robot
2018-06-26 17:31 ` [PATCH 5/6] x86,mm: always use lazy TLB mode Rik van Riel
2018-06-26 17:31 ` [PATCH 6/6] x86,switch_mm: skip atomic operations for init_mm Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1530216318.16379.4.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=efault@gmx.de \
    --cc=kernel-team@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=songliubraving@fb.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.