From: Shaohua Li <shaohua.li@intel.com>
To: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Hugh Dickins <hughd@google.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Andi Kleen <andi@firstfloor.org>
Subject: Re: [patch]x86: avoid unnecessary tlb flush
Date: Mon, 23 Aug 2010 08:43:28 +0800 [thread overview]
Message-ID: <20100823004328.GA9766@sli10-desk.sh.intel.com> (raw)
In-Reply-To: <20100816011655.GA362@sli10-desk.sh.intel.com>
On Mon, Aug 16, 2010 at 09:16:55AM +0800, Shaohua Li wrote:
> On Sat, Aug 14, 2010 at 07:00:37AM +0800, Siddha, Suresh B wrote:
> > On Fri, 2010-08-13 at 14:08 -0700, H. Peter Anvin wrote:
> > > On 08/13/2010 12:29 PM, Hugh Dickins wrote:
> > > >
> > > > Just added Andrea to the Cc list: he did that TLB flush in 1a44e149,
> > > > I'd feel more comfortable noop-ing it on x86 if you've convinced him.
> > > >
> > > > Hugh
> > >
> > > Andrea is probably on his way back from LinuxCon, but looking at the
> > > original patch it might be something that non-x86 architectures need,
> > > but which can be optimized specifically on x86, since x86 has explicit
> > > "no flush needed when going to more permissive" semantics.
> >
> > Yes. I don't see a problem with the proposed patch. This is the case of
> > parallel thread execution getting spurious write protection faults for
> > the same page for which the pte entry is already up to date and the
> > fault has already flushed the existing spurious TLB entry in the case of
> > x86.
> >
> > I prefer a better name for the new flush_tlb_nonprotect_page() to
> > reflect the above. something like tlb_fix_spurious_fault() or something?
> this name is better.
Hi Andrea,
can you look at this patch?
Thanks,
Shaohua
> In x86, access and dirty bits are set automatically by CPU when CPU accesses
> memory. When we go into the code path of below flush_tlb_fix_spurious_fault(),
> we already set dirty bit for pte and don't need flush tlb. This might mean
> tlb entry in some CPUs hasn't dirty bit set, but this doesn't matter. When
> the CPUs do page write, they will automatically check the bit and no software
> involved.
>
> On the other hand, flush tlb in below position is harmful. Test creates CPU
> number of threads, each thread writes to a same but random address in same vma
> range and we measure the total time. Under a 4 socket system, original time is
> 1.96s, while with the patch, the time is 0.8s. Under a 2 socket system, there is
> 20% time cut too. perf shows a lot of time are taking to send ipi/handle ipi for
> tlb flush.
>
> Signed-off-by: Shaohua Li <shaohua.li@intel.com>
> Acked-by: Suresh Siddha <suresh.b.siddha@intel.com>
>
> ---
> arch/x86/include/asm/pgtable.h | 2 ++
> include/asm-generic/pgtable.h | 4 ++++
> mm/memory.c | 2 +-
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> Index: linux/arch/x86/include/asm/pgtable.h
> ===================================================================
> --- linux.orig/arch/x86/include/asm/pgtable.h 2010-08-16 09:00:02.000000000 +0800
> +++ linux/arch/x86/include/asm/pgtable.h 2010-08-16 09:03:41.000000000 +0800
> @@ -603,6 +603,8 @@ static inline void ptep_set_wrprotect(st
> pte_update(mm, addr, ptep);
> }
>
> +#define flush_tlb_fix_spurious_fault(vma, address)
> +
> /*
> * clone_pgd_range(pgd_t *dst, pgd_t *src, int count);
> *
> Index: linux/include/asm-generic/pgtable.h
> ===================================================================
> --- linux.orig/include/asm-generic/pgtable.h 2010-08-16 09:00:02.000000000 +0800
> +++ linux/include/asm-generic/pgtable.h 2010-08-16 09:03:41.000000000 +0800
> @@ -129,6 +129,10 @@ static inline void ptep_set_wrprotect(st
> #define move_pte(pte, prot, old_addr, new_addr) (pte)
> #endif
>
> +#ifndef flush_tlb_fix_spurious_fault
> +#define flush_tlb_fix_spurious_fault(vma, address) flush_tlb_page(vma, address)
> +#endif
> +
> #ifndef pgprot_noncached
> #define pgprot_noncached(prot) (prot)
> #endif
> Index: linux/mm/memory.c
> ===================================================================
> --- linux.orig/mm/memory.c 2010-08-16 09:03:08.000000000 +0800
> +++ linux/mm/memory.c 2010-08-16 09:03:41.000000000 +0800
> @@ -3140,7 +3140,7 @@ static inline int handle_pte_fault(struc
> * with threads.
> */
> if (flags & FAULT_FLAG_WRITE)
> - flush_tlb_page(vma, address);
> + flush_tlb_fix_spurious_fault(vma, address);
> }
> unlock:
> pte_unmap_unlock(pte, ptl);
next prev parent reply other threads:[~2010-08-23 0:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 3:28 Shaohua Li
2010-08-06 5:19 ` Andrew Morton
2010-08-13 0:47 ` Shaohua Li
2010-08-13 19:29 ` Hugh Dickins
2010-08-13 21:08 ` H. Peter Anvin
2010-08-13 23:00 ` Suresh Siddha
2010-08-16 1:16 ` Shaohua Li
2010-08-23 0:43 ` Shaohua Li [this message]
2010-08-23 17:57 ` [tip:x86/mm] x86, mm: Avoid unnecessary TLB flush tip-bot for Shaohua Li
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=20100823004328.GA9766@sli10-desk.sh.intel.com \
--to=shaohua.li@intel.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=suresh.b.siddha@intel.com \
/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
all inboxes | Powered by JetHome®