public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox