Comment 40 for bug 314928

Guys, I think this explains why 2.6.30RC2 performance is hugely better for me than 2.6.28-11.

I currently have two kernels installed.

2.6.30-020630rc2-generic
2.6.28-11.42-generic

Under the 30RC2 kernel, I see the following in kern.log (good news, I assume!)
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR default type: uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR fixed ranges enabled:
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 00000-9FFFF write-back
Apr 27 10:40:39 vademecum kernel: [ 0.000000] A0000-BFFFF uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] C0000-DBFFF write-protect
Apr 27 10:40:39 vademecum kernel: [ 0.000000] DC000-E7FFF write-through
Apr 27 10:40:39 vademecum kernel: [ 0.000000] E8000-FFFFF write-protect
Apr 27 10:40:39 vademecum kernel: [ 0.000000] MTRR variable ranges enabled:
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 0 base 000000000 mask 0C0000000 write-back
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 1 base 03F700000 mask 0FFF00000 uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 2 base 03F800000 mask 0FF800000 uncachable
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 3 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 4 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 5 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 6 disabled
Apr 27 10:40:39 vademecum kernel: [ 0.000000] 7 disabled

Under the 2.6.28 kernel I don't see ANY of that.

2.6.30RC2 /proc/mtrr (good!)
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable
reg03: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-combining

2.6.28 /proc/mtrr (bad)
reg00: base=0x000000000 ( 0MB), size= 1024MB, count=1: write-back
reg01: base=0x03f700000 ( 1015MB), size= 1MB, count=1: uncachable
reg02: base=0x03f800000 ( 1016MB), size= 8MB, count=1: uncachable

So whatever is done to fix this for 2.6.28 we'll need to be careful about regressions in 2.6.30.

May putting a hack into X startup is not the answer - this looks like a problem with the kernel MTRR startup, especially if this worked right in Intrepid. (If you did want to hack it, then /etc/kde4/kdm/Xsetup or Xstartup would be a good place for Kubuntu.)