linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chuck Ebbert <cebbert.lkml@gmail.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
	linux-kernel@vger.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Jiri Kosina <jkosina@suse.cz>,
	Steven Rostedt <rostedt@goodmis.org>,
	Jason Baron <jbaron@akamai.com>,
	yrl.pp-manager.tt@hitachi.com, Borislav Petkov <bpetkov@suse.de>,
	Ingo Molnar <mingo@kernel.org>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Dave Jones <davej@redhat.com>
Subject: Re: i915.ko WC writes are slow after ea8596bb2d8d379
Date: Thu, 9 Oct 2014 09:46:37 -0500	[thread overview]
Message-ID: <20141009094637.4f3f61e2@as> (raw)
In-Reply-To: <20141009130047.GJ12897@nuc-i3427.alporthouse.com>

On Thu, 9 Oct 2014 14:00:47 +0100
Chris Wilson <chris@chris-wilson.co.uk> wrote:

> On Thu, Oct 09, 2014 at 07:44:16AM -0500, Chuck Ebbert wrote:
> > Could you try installing x86info and running "x86info --mtrr
> > --all-cpus" while running the broken kernel?
> 
> # /opt/xorg/src/intel-gpu-tools/tests/gem_gtt_speed 
> IGT-Version: 1.8-g32a0308 (x86_64) (Linux: 3.17.0+ x86_64)
> Time to read 16k through a GTT map:             318.643µs
> Time to write 16k through a GTT map:            203.103µs
> Time to clear 16k through a GTT map:             53.098µs
> Time to clear 16k through a cached GTT map:      49.925µs
> 
> (i.e. bad kernel)
> 
> # x86info --mtrr --all-cpus
> x86info v1.30.  Dave Jones 2001-2011
> Feedback to <davej@redhat.com>.
> 
> Found 4 CPUs.
> CPU #1:
> Extended Family: 0 Extended Model: 2 Family: 6 Model: 42 Stepping: 7
> Type: 0 (Original OEM)
> CPU Model (x86info's best guess): Unknown model. 
> Processor name string (BIOS programmed): Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz
> 
> MTRR registers:
> MTRRcap (0xfe): 0x0000000000000d0a (smrr flag: 0x1, wc flag: 0x1, fix flag: 0x1, vcnt field: 0x0a (10))
> MTRRphysBase0 (0x200): 0x0000000000000006 (physbase field:0x000000 type field: 0x06 (write-back))
> MTRRphysMask0 (0x201): 0x0000000f80000800 (physmask field:0xf80000 valid flag: 1)
> MTRRphysBase1 (0x202): 0x0000000080000006 (physbase field:0x080000 type field: 0x06 (write-back))
> MTRRphysMask1 (0x203): 0x0000000ff0000800 (physmask field:0xff0000 valid flag: 1)
> MTRRphysBase2 (0x204): 0x000000008e000000 (physbase field:0x08e000 type field: 0x00 (uncacheable))
> MTRRphysMask2 (0x205): 0x0000000ffe000800 (physmask field:0xffe000 valid flag: 1)
> MTRRphysBase3 (0x206): 0x000000008d000000 (physbase field:0x08d000 type field: 0x00 (uncacheable))
> MTRRphysMask3 (0x207): 0x0000000fff000800 (physmask field:0xfff000 valid flag: 1)
> MTRRphysBase4 (0x208): 0x0000000100000006 (physbase field:0x100000 type field: 0x06 (write-back))
> MTRRphysMask4 (0x209): 0x0000000f80000800 (physmask field:0xf80000 valid flag: 1)
> MTRRphysBase5 (0x20a): 0x0000000170000000 (physbase field:0x170000 type field: 0x00 (uncacheable))
> MTRRphysMask5 (0x20b): 0x0000000ff0000800 (physmask field:0xff0000 valid flag: 1)
> MTRRphysBase6 (0x20c): 0x000000016f000000 (physbase field:0x16f000 type field: 0x00 (uncacheable))
> MTRRphysMask6 (0x20d): 0x0000000fff000800 (physmask field:0xfff000 valid flag: 1)
> MTRRphysBase7 (0x20e): 0x000000016e800000 (physbase field:0x16e800 type field: 0x00 (uncacheable))
> MTRRphysMask7 (0x20f): 0x0000000fff800800 (physmask field:0xfff800 valid flag: 1)
> MTRRfix64K_00000 (0x250): 0x0606060606060606
> MTRRfix16K_80000 (0x258): 0x0606060606060606
> MTRRfix16K_A0000 (0x259): 0x0000000000000000
> MTRRfix4K_C8000 (0x269): 0x0505050505050505
> MTRRfix4K_D0000 0x26a: 0x0000000000000000
> MTRRfix4K_D8000 0x26b: 0x0000000000000000
> MTRRfix4K_E0000 0x26c: 0x0000000000000000
> MTRRfix4K_E8000 0x26d: 0x0505050505050505
> MTRRfix4K_F0000 0x26e: 0x0505050505050505
> MTRRfix4K_F8000 0x26f: 0x0505050505050505
> MTRRdefType (0x2ff): 0x0000000000000c00 (fixed-range flag: 0x1, mtrr flag: 0x1, type field: 0x00 (uncacheable))
> 

<snip>

Well they're all the same.

Hmm, x86info is not dumping all the variable MTRRs. You have 10, but
it only prints the first 8. I don't know if it will show anything
different, but can you try fixing it with this patch?

--- a/mtrr.c
+++ b/mtrr.c
@@ -75,19 +75,23 @@
 		printf("0x%016llx\n", val);
 }
 
-static void decode_mtrrcap(int cpu, int msr)
+unsigned int decode_mtrrcap(int cpu, int msr)
 {
 	unsigned long long val;
+	unsigned int vcnt = 0;
 	int ret;
 
 	ret = mtrr_value(cpu,msr,&val);
 	if (ret) {
+		vcnt = (unsigned int)(val & IA32_MTRRCAP_VCNT);
 		printf("0x%016llx ", val);
 		printf("(smrr flag: 0x%01x, ",(unsigned int) (val & IA32_MTRRCAP_SMRR) >> 11 );
 		printf("wc flag: 0x%01x, ",(unsigned int) (val&IA32_MTRRCAP_WC) >> 10);
 		printf("fix flag: 0x%01x, ",(unsigned int) (val&IA32_MTRRCAP_FIX) >> 8);
-		printf("vcnt field: 0x%02x (%d))\n",(unsigned int) (val&IA32_MTRRCAP_VCNT) , (int) (val&IA32_MTRRCAP_VCNT));
+		printf("vcnt field: 0x%02x (%u))\n", vcnt, vcnt);
 	}
+
+	return vcnt;
 }
 
 static void decode_mtrr_deftype(int cpu, int msr)
@@ -142,7 +146,7 @@
 void dump_mtrrs(struct cpudata *cpu)
 {
 	unsigned long long val = 0;
-	unsigned int i;
+	unsigned int i, vcnt;
 
 	if (!(cpu->flags_edx & (X86_FEATURE_MTRR)))
 		return;
@@ -157,11 +161,11 @@
 	printf("MTRR registers:\n");
 
 	printf("MTRRcap (0xfe): ");
-	decode_mtrrcap(cpu->number, 0xfe);
+	vcnt = decode_mtrrcap(cpu->number, 0xfe);
 
 	set_max_phy_addr(cpu);
 
-	for (i = 0; i < 16; i+=2) {
+	for (i = 0; i < 2 * vcnt; i += 2) {
 		printf("MTRRphysBase%u (0x%x): ", i/2, (unsigned int) 0x200+i);
 		decode_mtrr_physbase(cpu->number, 0x200+i);
 		printf("MTRRphysMask%u (0x%x): ", i/2, (unsigned int) 0x201+i);

  reply	other threads:[~2014-10-09 14:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-08  9:03 i915.ko WC writes are slow after ea8596bb2d8d379 Chris Wilson
2014-10-08 10:10 ` Chuck Ebbert
2014-10-08 19:49   ` Chris Wilson
2014-10-08 21:36     ` H. Peter Anvin
2014-10-09  6:53       ` Chris Wilson
2014-10-09 12:44         ` Chuck Ebbert
2014-10-09 13:00           ` Chris Wilson
2014-10-09 14:46             ` Chuck Ebbert [this message]
2014-10-09 15:14               ` Chris Wilson
2015-11-18 14:48   ` Chris Wilson
2015-11-18 15:57     ` Andy Lutomirski
2015-11-19  8:14       ` Ingo Molnar
2015-11-19 10:03         ` [PATCH] kernel: Remove stop_machine() Kconfig dependency Chris Wilson
2015-11-19  8:16     ` i915.ko WC writes are slow after ea8596bb2d8d379 Ingo Molnar
2014-10-08 17:47 ` Chuck Ebbert
2014-10-09  1:45   ` Masami Hiramatsu

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=20141009094637.4f3f61e2@as \
    --to=cebbert.lkml@gmail.com \
    --cc=bpetkov@suse.de \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=davej@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=jbaron@akamai.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yrl.pp-manager.tt@hitachi.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;
as well as URLs for NNTP newsgroup(s).