All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@amd64.org>
To: Alex Shi <alex.shi@intel.com>
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
	arnd@arndb.de, rostedt@goodmis.org, fweisbec@gmail.com,
	jeremy@goop.org, luto@mit.edu, yinghai@kernel.org,
	riel@redhat.com, avi@redhat.com, len.brown@intel.com,
	tj@kernel.org, akpm@linux-foundation.org, cl@gentwo.org,
	borislav.petkov@amd.com, ak@linux.intel.com, jbeulich@suse.com,
	eric.dumazet@gmail.com, akinobu.mita@gmail.com,
	vapier@gentoo.org, cpw@sgi.com, steiner@sgi.com,
	viro@zeniv.linux.org.uk, kamezawa.hiroyu@jp.fujitsu.com,
	rientjes@google.com, aarcange@redhat.com,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 7/9] x86/tlb: enable tlb flush range support for x86
Date: Thu, 19 Jul 2012 14:20:58 +0200	[thread overview]
Message-ID: <20120719122057.GA21666@aftab.osrc.amd.com> (raw)
In-Reply-To: <1340845344-27557-8-git-send-email-alex.shi@intel.com>

On Thu, Jun 28, 2012 at 09:02:22AM +0800, Alex Shi wrote:
> Not every tlb_flush execution moment is really need to evacuate all
> TLB entries, like in munmap, just few 'invlpg' is better for whole
> process performance, since it leaves most of TLB entries for later
> accessing.
> 
> This patch also rewrite flush_tlb_range for 2 purposes:
> 1, split it out to get flush_blt_mm_range function.
> 2, clean up to reduce line breaking, thanks for Borislav's input.
> 
> My micro benchmark 'mummap' http://lkml.org/lkml/2012/5/17/59
> show that the random memory access on other CPU has 0~50% speed up
> on a 2P * 4cores * HT NHM EP while do 'munmap'.
> 
> Thanks Yongjie's testing on this patch:
> -------------
> I used Linux 3.4-RC6 w/ and w/o his patches as Xen dom0 and guest
> kernel.
> After running two benchmarks in Xen HVM guest, I found his patches
> brought about 1%~3% performance gain in 'kernel build' and 'netperf'
> testing, though the performance gain was not very stable in 'kernel
> build' testing.
> 
> Some detailed testing results are below.
> 
> Testing Environment:
> 	Hardware: Romley-EP platform
> 	Xen version: latest upstream
> 	Linux kernel: 3.4-RC6
> 	Guest vCPU number: 8
> 	NIC: Intel 82599 (10GB bandwidth)
> 
> In 'kernel build' testing in guest:
> 	Command line  |  performance gain
>     make -j 4      |    3.81%
>     make -j 8      |    0.37%
>     make -j 16     |    -0.52%
> 
> In 'netperf' testing, we tested TCP_STREAM with default socket size
> 16384 byte as large packet and 64 byte as small packet.
> I used several clients to add networking pressure, then 'netperf' server
> automatically generated several threads to response them.
> I also used large-size packet and small-size packet in the testing.
> 	Packet size  |  Thread number | performance gain
> 	16384 bytes  |      4       |   0.02%
> 	16384 bytes  |      8       |   2.21%
> 	16384 bytes  |      16      |   2.04%
> 	64 bytes     |      4       |   1.07%
> 	64 bytes     |      8       |   3.31%
> 	64 bytes     |      16      |   0.71%
> 
> Signed-off-by: Alex Shi <alex.shi@intel.com>
> Tested-by: Ren, Yongjie <yongjie.ren@intel.com>
> ---
>  arch/x86/include/asm/tlb.h      |    9 +++-
>  arch/x86/include/asm/tlbflush.h |   17 +++++-
>  arch/x86/mm/tlb.c               |  112 ++++++++++++++++-----------------------
>  3 files changed, 68 insertions(+), 70 deletions(-)
> 
> diff --git a/arch/x86/include/asm/tlb.h b/arch/x86/include/asm/tlb.h
> index 829215f..4fef207 100644
> --- a/arch/x86/include/asm/tlb.h
> +++ b/arch/x86/include/asm/tlb.h
> @@ -4,7 +4,14 @@
>  #define tlb_start_vma(tlb, vma) do { } while (0)
>  #define tlb_end_vma(tlb, vma) do { } while (0)
>  #define __tlb_remove_tlb_entry(tlb, ptep, address) do { } while (0)
> -#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
> +
> +#define tlb_flush(tlb)							\
> +{									\
> +	if (tlb->fullmm == 0)						\
> +		flush_tlb_mm_range(tlb->mm, tlb->start, tlb->end, 0UL);	\
> +	else								\
> +		flush_tlb_mm_range(tlb->mm, 0UL, TLB_FLUSH_ALL, 0UL);	\
> +}
>  
>  #include <asm-generic/tlb.h>
>  
> diff --git a/arch/x86/include/asm/tlbflush.h b/arch/x86/include/asm/tlbflush.h
> index 33608d9..621b959 100644
> --- a/arch/x86/include/asm/tlbflush.h
> +++ b/arch/x86/include/asm/tlbflush.h
> @@ -105,6 +105,13 @@ static inline void flush_tlb_range(struct vm_area_struct *vma,
>  		__flush_tlb();
>  }
>  
> +static inline void flush_tlb_mm_range(struct vm_area_struct *vma,
> +	   unsigned long start, unsigned long end, unsigned long vmflag)
> +{
> +	if (vma->vm_mm == current->active_mm)
> +		__flush_tlb();
> +}

There's a problem with this in one of my randconfig tests. It has
!CONFIG_SMP and the warning is:

mm/memory.c: In function ‘tlb_flush_mmu’:
mm/memory.c:230:2: warning: passing argument 1 of ‘flush_tlb_mm_range’ from incompatible pointer type
/usr/src/linux-2.6/arch/x86/include/asm/tlbflush.h:108:20: note: expected ‘struct vm_area_struct *’ but argument is of type ‘struct mm_struct *’
mm/memory.c:230:2: warning: passing argument 1 of ‘flush_tlb_mm_range’ from incompatible pointer type
/usr/src/linux-2.6/arch/x86/include/asm/tlbflush.h:108:20: note: expected ‘struct vm_area_struct *’ but argument is of type ‘struct mm_struct *’


Due to the fact that the macro flush_tlb actually resolves to
flush_tlb_mm_range and this function has a different signature based on
CONFIG_SMP. On !SMP expects struct vm_area_struct * as a first argument
but on SMP its first argument is struct mm_struct *.

So two different function signatures based on a config option? Now
that's a first. What is going on?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

  parent reply	other threads:[~2012-07-19 12:21 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-28  1:02 [PATCH v10 0/9] X86 TLB flush optimization Alex Shi
2012-06-28  1:02 ` [PATCH v10 1/9] x86/tlb_info: get last level TLB entry number of CPU Alex Shi
2012-06-28 15:37   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 2/9] x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range Alex Shi
2012-06-28 15:38   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 3/9] x86/tlb: fall back to flush all when meet a THP large page Alex Shi
2012-06-28 15:39   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 4/9] x86/tlb: add tlb_flushall_shift for specific CPU Alex Shi
2012-06-28 15:40   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 5/9] x86/tlb: add tlb_flushall_shift knob into debugfs Alex Shi
2012-06-28 15:41   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 6/9] mm/mmu_gather: enable tlb flush range in generic mmu_gather Alex Shi
2012-06-28 15:42   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 7/9] x86/tlb: enable tlb flush range support for x86 Alex Shi
2012-06-28 15:42   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-07-19 12:20   ` Borislav Petkov [this message]
2012-07-19 23:52     ` [PATCH v10 7/9] " Alex Shi
2012-07-19 23:56       ` H. Peter Anvin
2012-07-20  0:06         ` Alex Shi
2012-07-20  0:44           ` H. Peter Anvin
2012-06-28  1:02 ` [PATCH v10 8/9] x86/tlb: replace INVALIDATE_TLB_VECTOR by CALL_FUNCTION_VECTOR Alex Shi
2012-06-28 15:43   ` [tip:x86/mm] " tip-bot for Alex Shi
2012-06-28  1:02 ` [PATCH v10 9/9] x86/tlb: do flush_tlb_kernel_range by 'invlpg' Alex Shi
2012-06-28 15:44   ` [tip:x86/mm] " tip-bot for Alex Shi

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=20120719122057.GA21666@aftab.osrc.amd.com \
    --to=bp@amd64.org \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=akinobu.mita@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@intel.com \
    --cc=arnd@arndb.de \
    --cc=avi@redhat.com \
    --cc=borislav.petkov@amd.com \
    --cc=cl@gentwo.org \
    --cc=cpw@sgi.com \
    --cc=eric.dumazet@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=jbeulich@suse.com \
    --cc=jeremy@goop.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=mingo@redhat.com \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=rostedt@goodmis.org \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vapier@gentoo.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=yinghai@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.