All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joerg.roedel@amd.com>
To: Andi Kleen <andi@firstfloor.org>
Cc: andreas.herrmann3@amd.com, tglx@linutronix.de, mingo@elte.hu,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [6/7] Split large page mapping for AMD TSEG
Date: Tue, 25 Mar 2008 12:56:59 +0100	[thread overview]
Message-ID: <20080325115659.GM17986@amd.com> (raw)
In-Reply-To: <20080312025332.B5DFC1B41D1@basil.firstfloor.org>

On Wed, Mar 12, 2008 at 03:53:32AM +0100, Andi Kleen wrote:
> 
> On AMD SMM protected memory is part of the address map, but handled
> internally like an MTRR. That leads to large pages getting split
> internally which has some performance implications. Check for the
> AMD TSEG MSR and split the large page mapping on that area 
> explicitely if it is part of the direct mapping. 
> 
> There is also SMM ASEG, but it is in the first 1MB and already covered by 
> the earlier split first page patch.
> 
> Idea for this came from an earlier patch by Andreas Herrmann
> 
> On a RevF dual Socket Opteron system kernbench shows a clear
> improvement from this:
> (together with the earlier patches in this series, especially the 
> split first 2MB patch) 
> 
> [lower is better]
>               no split stddev         split  stddev    delta
> Elapsed Time   87.146 (0.727516)     84.296 (1.09098)  -3.2%
> User Time     274.537 (4.05226)     273.692 (3.34344)  -0.3%
> System Time    34.907 (0.42492)      34.508 (0.26832)  -1.1%
> Percent CPU   322.5   (38.3007)     326.5   (44.5128)  +1.2%
> 
> => About 3.2% improvement in elapsed time for kernbench.
> 
> With GB pages on AMD Fam1h the impact of splitting is much higher of course,
> since it would split two full GB pages (together with the first
> 1MB split patch) instead of two 2MB pages.  I could not benchmark
> a clear difference in kernbench on gbpages, so I kept it disabled
> for that case
> 
> That was only limited benchmarking of course, so if someone
> was interested in running more tests for the gbpages case
> that could be revisited (contributions welcome)
> 
> I didn't bother implementing this for 32bit because it is very
> unlikely the 32bit lowmem mapping overlaps into the TSEG near 4GB
> and the 2MB low split is already handled for both.
> 
> Signed-off-by: Andi Kleen <ak@suse.de>
Acked-by: Joerg Roedel <joerg.roedel@amd.com>


> ---
>  arch/x86/kernel/setup_64.c  |   13 +++++++++++++
>  include/asm-x86/msr-index.h |    1 +
>  2 files changed, 14 insertions(+)
> 
> Index: linux/arch/x86/kernel/setup_64.c
> ===================================================================
> --- linux.orig/arch/x86/kernel/setup_64.c
> +++ linux/arch/x86/kernel/setup_64.c
> @@ -721,6 +721,20 @@ static void __cpuinit init_amd(struct cp
>  
>  	if (amd_apic_timer_broken())
>  		disable_apic_timer = 1;
> +
> +	if (!direct_gbpages &&
> +		c == &boot_cpu_data && c->x86 >= 0xf && c->x86 <= 0x11) {
> +		unsigned long tseg;
> +
> +		/*
> +		 * Split up direct mapping around the TSEG SMM area.
> +		 * Don't do it for gbpages because there seems very little
> +		 * benefit in doing so.
> +		 */
> +		if (!rdmsrl_safe(MSR_K8_TSEG_ADDR, &tseg) &&
> +		(tseg >> PMD_SHIFT) < (end_pfn_map >> (PMD_SHIFT-PAGE_SHIFT)))
> +			set_memory_4k((unsigned long)__va(tseg), 1);
> +	}
>  }
>  
>  void __cpuinit detect_ht(struct cpuinfo_x86 *c)
> Index: linux/include/asm-x86/msr-index.h
> ===================================================================
> --- linux.orig/include/asm-x86/msr-index.h
> +++ linux/include/asm-x86/msr-index.h
> @@ -109,6 +109,7 @@
>  #define MSR_K8_SYSCFG			0xc0010010
>  #define MSR_K8_HWCR			0xc0010015
>  #define MSR_K8_ENABLE_C1E		0xc0010055
> +#define MSR_K8_TSEG_ADDR		0xc0010112
>  #define K8_MTRRFIXRANGE_DRAM_ENABLE	0x00040000 /* MtrrFixDramEn bit    */
>  #define K8_MTRRFIXRANGE_DRAM_MODIFY	0x00080000 /* MtrrFixDramModEn bit */
>  #define K8_MTRR_RDMEM_WRMEM_MASK	0x18181818 /* Mask: RdMem|WrMem    */
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
           |           AMD Saxony Limited Liability Company & Co. KG
 Operating |         Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 System    |                  Register Court Dresden: HRA 4896
 Research  |              General Partner authorized to represent:
 Center    |             AMD Saxony LLC (Wilmington, Delaware, US)
           | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


  parent reply	other threads:[~2008-03-25 11:57 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12  2:53 [PATCH] [1/7] Implement true end_pfn_mapped for 32bit Andi Kleen
2008-03-12  2:53 ` [PATCH] [2/7] Account overlapped mappings in end_pfn_map Andi Kleen
2008-03-12  2:53 ` [PATCH] [3/7] Add set_memory_4k to pageattr.c Andi Kleen
2008-03-12  2:53 ` [PATCH] [4/7] Don't use large pages to map the first 2/4MB of memory Andi Kleen
2008-03-12  5:38   ` Eric Dumazet
2008-03-12  9:19     ` Andi Kleen
2008-03-21 17:45   ` Thomas Gleixner
2008-03-21 17:59     ` Andi Kleen
2008-03-21 18:03       ` Thomas Gleixner
2008-03-21 18:44         ` Andi Kleen
2008-03-25 11:31   ` Joerg Roedel
2008-03-25 11:39     ` Andi Kleen
2008-03-12  2:53 ` [PATCH] [5/7] Readd rdmsrl_safe Andi Kleen
2008-03-21 17:06   ` Thomas Gleixner
2008-03-21 17:16     ` Andi Kleen
2008-03-21 17:58       ` Thomas Gleixner
2008-03-21 18:06         ` Andi Kleen
2008-03-21 18:14           ` Thomas Gleixner
2008-03-21 18:46             ` Andi Kleen
2008-03-21 18:48               ` [PATCH] [5/7] Readd rdmsrl_safe II Andi Kleen
2008-03-22  9:59     ` [PATCH] Readd rdmsrl_safe v2 Andi Kleen
2008-03-12  2:53 ` [PATCH] [6/7] Split large page mapping for AMD TSEG Andi Kleen
2008-03-21 17:55   ` Thomas Gleixner
2008-03-25 11:56   ` Joerg Roedel [this message]
2008-03-25 16:44   ` Thomas Gleixner
2008-03-25 16:54     ` Andi Kleen
2008-03-12  2:53 ` [PATCH] [7/7] CPA: Add statistics about state of direct mapping v2 Andi Kleen
2008-03-21 17:41   ` Thomas Gleixner
2008-03-21 17:55     ` Andi Kleen
2008-03-22  9:50       ` [PATCH] CPA: Add statistics about state of direct mapping v3 Andi Kleen
2008-03-25 15:40         ` Thomas Gleixner
2008-03-25 16:14           ` Andi Kleen
2008-03-25 16:16             ` Thomas Gleixner
2008-03-25 17:01               ` [PATCH] CPA: Add statistics about state of direct mapping v4 Andi Kleen

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=20080325115659.GM17986@amd.com \
    --to=joerg.roedel@amd.com \
    --cc=andi@firstfloor.org \
    --cc=andreas.herrmann3@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /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.