linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Nadav Amit <namit@vmware.com>
Cc: Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH] x86/mm/tlb: Remove flush_tlb_info from the stack
Date: Tue, 23 Apr 2019 10:23:47 -0700	[thread overview]
Message-ID: <CALCETrXLjL4vMwQP1tweWvk_+dBvZFdE85ckt8TZSVw2XyW_yQ@mail.gmail.com> (raw)
In-Reply-To: <44A66873-0834-4794-81A5-3B2131314AA4@vmware.com>

On Tue, Apr 23, 2019 at 9:56 AM Nadav Amit <namit@vmware.com> wrote:
>
> > On Apr 23, 2019, at 9:50 AM, Andy Lutomirski <luto@kernel.org> wrote:
> >
> > On Tue, Apr 23, 2019 at 12:12 AM Nadav Amit <namit@vmware.com> wrote:
>https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/fixes >> Remove flush_tlb_info variables from the stack. This allows to align
> >> flush_tlb_info to cache-line and avoid potentially unnecessary cache
> >> line movements. It also allows to have a fixed virtual-to-physical
> >> translation of the variables, which reduces TLB misses.
> >>
> >> Use per-CPU struct for flush_tlb_mm_range() and
> >> flush_tlb_kernel_range(). Add debug assertions to ensure there are
> >> no nested TLB flushes that might overwrite the per-CPU data. For
> >> arch_tlbbatch_flush(), use a const struct.
> >>
> >> Results when running a microbenchmarks that performs 10^6 MADV_DONTEED
> >> operations and touching a page, in which 3 additional threads run a
> >> busy-wait loop (5 runs):
> >
> > Can you add a memset(,,,. 0, sizeof(struct flush_tlb_info)) everywhere
> > you grab it?  Or, even better, perhaps do something like:
> >
> > static inline struct flush_tlb_info *get_flush_tlb_info(void)
> > {
> >  /* check reentrancy, make sure that we use smp_processor_id() or
> > otherwise assert that we're bound to a single CPU. */
> >  struct flush_tlb_info *ptr = this_cpu_ptr(...);
> >  memset(ptr, 0, sizeof(*ptr));
> >  return ptr;
> > }
> >
> > static inline void put_flush_tlb_info(void)
> > {
> > /* finish checking reentrancy. */
> > }
>
> I’ll check if the compiler is smart enough to avoid redundant assignments,
> and if it is not, I’ll just give all the struct arguments to
> get_flush_tlb_info() instead of memset() if you don’t mind.

Sounds good.

>
> I also want to give a try for parallelizing the remote and local
> invocations, which really annoys me every time I look at the code.

Yes please!

  reply	other threads:[~2019-04-23 17:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-23  6:57 [PATCH] x86/mm/tlb: Remove flush_tlb_info from the stack Nadav Amit
2019-04-23 16:50 ` Andy Lutomirski
2019-04-23 16:56   ` Nadav Amit
2019-04-23 17:23     ` Andy Lutomirski [this message]
2019-04-25 18:13       ` Nadav Amit

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=CALCETrXLjL4vMwQP1tweWvk_+dBvZFdE85ckt8TZSVw2XyW_yQ@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).