From: Dave Hansen <dave.hansen@intel.com>
To: Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Borislav Petkov <bpetkov@suse.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Rik van Riel <riel@redhat.com>, Nadav Amit <namit@vmware.com>,
Michal Hocko <mhocko@suse.com>,
Sasha Levin <sasha.levin@oracle.com>
Subject: Re: [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic
Date: Mon, 8 May 2017 08:34:58 -0700 [thread overview]
Message-ID: <d36207ef-a4b3-24ef-40e4-9e6a22b092cb@intel.com> (raw)
In-Reply-To: <983c5ee661d8fe8a70c596c4e77076d11ce3f80a.1494160201.git.luto@kernel.org>
On 05/07/2017 05:38 AM, Andy Lutomirski wrote:
> diff --git a/mm/rmap.c b/mm/rmap.c
> index f6838015810f..2e568c82f477 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -579,25 +579,12 @@ void page_unlock_anon_vma_read(struct anon_vma *anon_vma)
> void try_to_unmap_flush(void)
> {
> struct tlbflush_unmap_batch *tlb_ubc = ¤t->tlb_ubc;
> - int cpu;
>
> if (!tlb_ubc->flush_required)
> return;
>
> - cpu = get_cpu();
> -
> - if (cpumask_test_cpu(cpu, &tlb_ubc->cpumask)) {
> - count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
> - local_flush_tlb();
> - trace_tlb_flush(TLB_LOCAL_SHOOTDOWN, TLB_FLUSH_ALL);
> - }
> -
> - if (cpumask_any_but(&tlb_ubc->cpumask, cpu) < nr_cpu_ids)
> - flush_tlb_others(&tlb_ubc->cpumask, NULL, 0, TLB_FLUSH_ALL);
> - cpumask_clear(&tlb_ubc->cpumask);
> tlb_ubc->flush_required = false;
> tlb_ubc->writable = false;
> - put_cpu();
> }
>
> /* Flush iff there are potentially writable TLB entries that can race with IO */
> @@ -613,7 +600,7 @@ static void set_tlb_ubc_flush_pending(struct mm_struct *mm, bool writable)
> {
> struct tlbflush_unmap_batch *tlb_ubc = ¤t->tlb_ubc;
>
> - cpumask_or(&tlb_ubc->cpumask, &tlb_ubc->cpumask, mm_cpumask(mm));
> + arch_tlbbatch_add_mm(&tlb_ubc->arch, mm);
> tlb_ubc->flush_required = true;
>
> /*
Looking at this patch in isolation, how can this be safe? It removes
TLB flushes from the generic code. Do other patches in the series fix
this up?
next prev parent reply other threads:[~2017-05-08 15:35 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-07 12:38 [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Andy Lutomirski
2017-05-07 12:38 ` [RFC 01/10] x86/mm: Reimplement flush_tlb_page() using flush_tlb_mm_range() Andy Lutomirski
2017-05-11 17:41 ` Borislav Petkov
2017-05-12 3:35 ` Andy Lutomirski
2017-05-07 12:38 ` [RFC 02/10] x86/mm: Reduce indentation in flush_tlb_func() Andy Lutomirski
2017-05-07 12:38 ` [RFC 03/10] x86/mm: Make the batched unmap TLB flush API more generic Andy Lutomirski
2017-05-08 15:34 ` Dave Hansen [this message]
2017-05-09 13:02 ` Andy Lutomirski
2017-05-09 14:39 ` Mel Gorman
2017-05-09 17:13 ` Dave Hansen
2017-05-09 22:54 ` Andy Lutomirski
2017-05-07 12:38 ` [RFC 04/10] x86/mm: Pass flush_tlb_info to flush_tlb_others() etc Andy Lutomirski
2017-05-11 20:01 ` Nadav Amit
2017-05-12 3:41 ` Andy Lutomirski
2017-05-07 12:38 ` [RFC 05/10] x86/mm: Change the leave_mm() condition for local TLB flushes Andy Lutomirski
2017-05-07 12:38 ` [RFC 06/10] x86/mm: Refactor flush_tlb_mm_range() to merge local and remote cases Andy Lutomirski
2017-05-07 12:38 ` [RFC 07/10] x86/mm: Use new merged flush logic in arch_tlbbatch_flush() Andy Lutomirski
2017-05-07 12:38 ` [RFC 08/10] x86/mm: Remove the UP tlbflush code; always use the formerly SMP code Andy Lutomirski
2017-05-07 12:38 ` [RFC 09/10] x86/mm: Rework lazy TLB to track the actual loaded mm Andy Lutomirski
2017-05-09 20:41 ` Thomas Gleixner
2017-05-09 22:54 ` Andy Lutomirski
2017-05-10 5:57 ` Ingo Molnar
2017-05-10 8:19 ` Thomas Gleixner
2017-05-10 8:24 ` Ingo Molnar
2017-05-10 22:42 ` Andy Lutomirski
2017-05-11 7:13 ` Ingo Molnar
2017-05-12 3:36 ` Andy Lutomirski
2017-05-07 12:38 ` [RFC 10/10] x86,kvm: Teach KVM's VMX code that CR3 isn't a constant Andy Lutomirski
2017-05-07 13:00 ` [RFC 00/10] x86 TLB flush cleanups, moving toward PCID support Ingo Molnar
2017-05-07 16:05 ` Linus Torvalds
2017-05-08 16:36 ` Nadav Amit
2017-05-09 12:43 ` Andy Lutomirski
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=d36207ef-a4b3-24ef-40e4-9e6a22b092cb@intel.com \
--to=dave.hansen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bpetkov@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=namit@vmware.com \
--cc=riel@redhat.com \
--cc=sasha.levin@oracle.com \
--cc=torvalds@linux-foundation.org \
--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