[PATCH] x86-64 highres/dyntick support

[PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

I'm pleased to announce the first cut of the final x86_64
highres/dyntick support, which I did based on Chris Wright's patch set,
which is again based on Arjan van de Ven's initial work:

http://www.tglx.de/projects/hrtimers/2.6.21-git2-x86-64/patches-2.6.21-git2.patch.bz2

Broken out version:

http://www.tglx.de/projects/hrtimers/2.6.21-git2-x86-64/patches-2.6.21-git2.tar.bz2

It applies on top of 2.6.21-git2 and contains the following patches:

# Andi's x86_64 queue (already in -mm and pending mainline merges)
x86_64-2.6.21-git2.patch 

# Outstanding fixups to highres/dyntick core and i386 
# (-mm and mainline pending)
highres-dyntick-avoid-xtime-lock-contention.patch
acpi-keep-tsc-stable-when-lapic-timer-c2-ok-is-set.patch
clocksource-fix-resume-logic.patch
clockevents-fix-resume-logic.patch

# x86_64 dyntick support
x86-64-untangle-hpet-headers.patch
x86-64-drive-set-rtc-mss.patch
i386-move-pit-setup-to-i8253-h.patch
x86-64-remove-dead-code-tsc-c.patch
x86-64-convert-to-clockevents.patch
x86-64-prepare-idle-for-dyntick.patch
x86-64-enable-highres-dyntick.patch

The x86-64-convert-to-clockevents.patch is rather large, but there is no
way to do this incremental. The clockevents conversion has to be done in
one go. 

The x86-64 clockevents patch set overall summary is:

 22 files changed, 631 insertions(+), 1199 deletions(-)

due to sharing the code of PIT and HPET with i386.

I did not dare to tackle sharing apic.c yet, but there is definitely a
chance to get this done some day when I get bored and do a:
# mkdir arch/x86  :)

I'm going to post the x86_64 set for review to LKML once the outstanding
highres/dyntick fixups have hit mainline resp. -mm

To create a highres / dyntick enabled kernel for x86_64:
http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.tar.bz2
http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.21-git2.bz2
http://www.tglx.de/projects/hrtimers/2.6.21-git2-x86-64/patches-2.6.21-git2.patch.bz2


Comments, bugreports, patches are welcome as ususal

Thanks,

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Nicolas Mailhot]

Thomas Gleixner <tglx <at> linutronix.de> writes:

> 
> I'm pleased to announce the first cut of the final x86_64
> highres/dyntick support, which I did based on Chris Wright's patch set,
> which is again based on Arjan van de Ven's initial work:

Do you have a 2.6.21-mm1 patchset?

Regards,

-- 
Nicolas Mailhot

Re: [PATCH] x86-64 highres/dyntick support

[Mats Johannesson]

On Sun May 06 2007 - Europe Evening Time Thomas Gleixner wrote:

> I'm pleased to announce the first cut of the final x86_64
> highres/dyntick support, which I did based on Chris Wright's patch
> set, which is again based on Arjan van de Ven's initial work:
[...]
> Comments, bugreports, patches are welcome as ususal

Are questions welcome? Then I'd ask: "What are the _minimal_ CPU
requirements to gain anything (eg less power consumption) with
dyntick?"

I ask because of a trial round with Chris Wright's patch set on a
fresh battery, idle system outside X with wifi card shut off and HZ
set to 100 (from my normal 1000):

root@sleipner:~# ls -l battest-the-new-battery/*
battest-the-new-battery/dyn-100hz-2.6.21:
total 4
-rw-r--r-- 1 root root  0 2007-04-27 00:50 start
-rw-r--r-- 1 root root  0 2007-04-27 03:54 stop
-rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash

battest-the-new-battery/plain-2.6.21:
total 4
-rw-r--r-- 1 root root  0 2007-04-27 13:16 start
-rw-r--r-- 1 root root  0 2007-04-27 16:22 stop
-rwxr-xr-x 1 root root 72 2007-04-26 22:16 test-batt.bash
root@sleipner:~#

The script just touched the "stop" file with a 2 minutes interval until
the machine died. As seen by the plus/minus 2 minutes results there is
absolutely no difference.

This AMD 64 Mobile processor only has a C1 level which isn't used:

root@sleipner:~# cat /proc/acpi/processor/CPU0/power
active state:            C1
max_cstate:              C8
bus master activity:     00000000
maximum allowed latency: 2000 usec
states:
   *C1:                  type[C1] promotion[--] demotion[--]
latency[000] usage[00000000] duration[00000000000000000000]

But shouldn't the the kernel 'hlt' routine, or whatever it's called,
work in conjunction with dyntick to achieve... something...?

CPU markings are:

Mobile AMD Athlon 64
AMA3400BEX5AR 1169004L40404
CAAZC 0451APMW 2001 AMD
Assembled in Malaysia

root@sleipner:~# cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 4
model name      : AMD Athlon(tm) 64 Processor 3400+
stepping        : 10
cpu MHz         : 800.000
cache size      : 1024 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm
3dnowext 3dnow
bogomips        : 1601.73
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp

Mvh,
Mats

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Mon, 2007-05-07 at 14:07 +0200, Mats Johannesson wrote:
> This AMD 64 Mobile processor only has a C1 level which isn't used:
> 
> root@sleipner:~# cat /proc/acpi/processor/CPU0/power
> active state:            C1
> max_cstate:              C8
> bus master activity:     00000000
> maximum allowed latency: 2000 usec
> states:
>    *C1:                  type[C1] promotion[--] demotion[--]
> latency[000] usage[00000000] duration[00000000000000000000]
> 
> But shouldn't the the kernel 'hlt' routine, or whatever it's called,
> work in conjunction with dyntick to achieve... something...?

To make real power savings from dynticks you need deeper power states in
the CPU. Dyntick can give the idle state code an idea how long the sleep
is going to be, so this code can decide to go into deeper power states
in one go rather than stepping down over time. On a CPU which has no
deeper C states the power saving of dynticks is probably not even
measurable,

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Mon, 2007-05-07 at 09:16 +0000, Nicolas Mailhot wrote:
> Thomas Gleixner <tglx <at> linutronix.de> writes:
> 
> > 
> > I'm pleased to announce the first cut of the final x86_64
> > highres/dyntick support, which I did based on Chris Wright's patch set,
> > which is again based on Arjan van de Ven's initial work:
> 
> Do you have a 2.6.21-mm1 patchset?

Not yet, but it should be halfways easy to do one. Stay tuned.

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> I'm pleased to announce the first cut of the final x86_64
> highres/dyntick support, which I did based on Chris Wright's patch set,
> which is again based on Arjan van de Ven's initial work:

Cool.  I had finished mine as well, just didn't get time to polish
and resubmit.  Going through to see where we differ and if there's
any bits of my set that yours needs.  

thanks,
-chris

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Mon, 2007-05-07 at 09:31 -0700, Chris Wright wrote:
> * Thomas Gleixner (tglx@linutronix.de) wrote:
> > I'm pleased to announce the first cut of the final x86_64
> > highres/dyntick support, which I did based on Chris Wright's patch set,
> > which is again based on Arjan van de Ven's initial work:
> 
> Cool.  I had finished mine as well, just didn't get time to polish
> and resubmit.

Hrmpf, you could have saved my weekend :)

>   Going through to see where we differ and if there's
> any bits of my set that yours needs.  

Yes please.

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> On Mon, 2007-05-07 at 09:31 -0700, Chris Wright wrote:
> > * Thomas Gleixner (tglx@linutronix.de) wrote:
> > > I'm pleased to announce the first cut of the final x86_64
> > > highres/dyntick support, which I did based on Chris Wright's patch set,
> > > which is again based on Arjan van de Ven's initial work:
> > 
> > Cool.  I had finished mine as well, just didn't get time to polish
> > and resubmit.
> 
> Hrmpf, you could have saved my weekend :)

Yeah, timing was just off, sorry about that.  I'm sure it'll improve
the end result ;-)

thanks,
-chris

Re: [PATCH] x86-64 highres/dyntick support

[Venki Pallipadi]

Needs this minor fix to build on i386.

Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>

Index: linux-2.6.21-tolkml/include/asm-i386/hpet.h
===================================================================
--- linux-2.6.21-tolkml.orig/include/asm-i386/hpet.h	2007-05-07 14:32:37.000000000 -0700
+++ linux-2.6.21-tolkml/include/asm-i386/hpet.h	2007-05-07 14:43:54.000000000 -0700
@@ -71,17 +71,6 @@
 #ifdef CONFIG_X86_64
 /* hpet_readl/writel defines */
 #include <asm/vsyscall.h>
-
-#else
-static inline unsigned long hpet_readl(unsigned long a)
-{
-	return readl(hpet_virt_address + a);
-}
-
-static inline void hpet_writel(unsigned long d, unsigned long a)
-{
-	writel(d, hpet_virt_address + a);
-}
 #endif
 
 #ifdef CONFIG_HPET_EMULATE_RTC
Index: linux-2.6.21-tolkml/arch/i386/kernel/hpet.c
===================================================================
--- linux-2.6.21-tolkml.orig/arch/i386/kernel/hpet.c	2007-05-07 14:31:34.000000000 -0700
+++ linux-2.6.21-tolkml/arch/i386/kernel/hpet.c	2007-05-07 14:43:36.000000000 -0700
@@ -47,6 +47,16 @@
 
 static void __iomem * hpet_virt_address;
 
+static inline unsigned long hpet_readl(unsigned long a)
+{
+	return readl(hpet_virt_address + a);
+}
+
+static inline void hpet_writel(unsigned long d, unsigned long a)
+{
+	writel(d, hpet_virt_address + a);
+}
+
 static inline void hpet_set_mapping(void)
 {
 	hpet_virt_address = ioremap_nocache(hpet_address, HPET_MMAP_SIZE);

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Mon, 2007-05-07 at 15:43 -0700, Venki Pallipadi wrote:
> Needs this minor fix to build on i386.

Ouch. 

Should have compiled i386 myself once more. There is another fixlet
missing in x86_64, which was caused by my inability to cope with the
intellegence of quilt.

Updated patches uploaded to:

http://www.tglx.de/projects/hrtimers/2.6.21-git2-x86-64/

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> On Mon, 2007-05-07 at 09:31 -0700, Chris Wright wrote:
> >   Going through to see where we differ and if there's
> > any bits of my set that yours needs.  
> 
> Yes please.

OK, looks very similar all things considered.  One thing I didn't do
was fix lapic timer calibration (was hoping you'd do that part, and you
did ;-)  I've noticed that something has changed and I'm seeing irq0
handled on cpu3 (4 cpu system), where it used to be on cpu0 as expected.
In addition lapic timer is firing there, and I'm seeing a higher
interrupt load than I used to.  This is the same in your set and mine.
Following is small set of patches that were the more obvious bits.

thanks,
-chris

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Tue, 2007-05-08 at 02:39 -0700, Chris Wright wrote:

> OK, looks very similar all things considered.  One thing I didn't do
> was fix lapic timer calibration (was hoping you'd do that part, and you
> did ;-)  I've noticed that something has changed and I'm seeing irq0
> handled on cpu3 (4 cpu system), where it used to be on cpu0 as expected.

Strange, irq balancing ?

> In addition lapic timer is firing there, and I'm seeing a higher
> interrupt load than I used to.  This is the same in your set and mine.

Is irq0 _and_ the lapic timer firing ?

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> On Tue, 2007-05-08 at 02:39 -0700, Chris Wright wrote:
> 
> > OK, looks very similar all things considered.  One thing I didn't do
> > was fix lapic timer calibration (was hoping you'd do that part, and you
> > did ;-)  I've noticed that something has changed and I'm seeing irq0
> > handled on cpu3 (4 cpu system), where it used to be on cpu0 as expected.
> 
> Strange, irq balancing ?

That's what I was wondering, although i have same setup for 32-bit
and it behaves as expected with cpu0 taking hpet or pit on irq0
and lapic timer picked up on the other 3 cpus.

> > In addition lapic timer is firing there, and I'm seeing a higher
> > interrupt load than I used to.  This is the same in your set and mine.
> 
> Is irq0 _and_ the lapic timer firing ?

Yes.

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Tue, 2007-05-08 at 02:51 -0700, Chris Wright wrote:
> That's what I was wondering, although i have same setup for 32-bit
> and it behaves as expected with cpu0 taking hpet or pit on irq0
> and lapic timer picked up on the other 3 cpus.
> 
> > > In addition lapic timer is firing there, and I'm seeing a higher
> > > interrupt load than I used to.  This is the same in your set and mine.
> > 
> > Is irq0 _and_ the lapic timer firing ?
> 
> Yes.

Hmm, that's even more strange. Can you please provide the output
of /proc/timer_list ?

	tglx

Re: [PATCH] x86-64 highres/dyntick support

[Chris Wright]

* Thomas Gleixner (tglx@linutronix.de) wrote:
> Hmm, that's even more strange. Can you please provide the output
> of /proc/timer_list ?

It's quite normal looking, and a printk in clockevents_set_mode looks normal too.

[chrisw@localhost ~]$ cat /proc/timer_list
Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 313565930359 nsecs

cpu: 0
 clock 0:
  .index:      0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .index:      1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
active timers:
 #0: <ffff810150223e38>, hrtimer_wakeup, S:01
 # expires at 313700587872 nsecs [in 134657513 nsecs]
 #1: <ffff810150223e38>, it_real_fn, S:01
 # expires at 332024684987 nsecs [in 18458754628 nsecs]
 #2: <ffff810150223e38>, hrtimer_wakeup, S:01
 # expires at 337032779067 nsecs [in 23466848708 nsecs]
 #3: <ffff810150223e38>, hrtimer_wakeup, S:01
 # expires at 1851212334864 nsecs [in 1537646404505 nsecs]
 #4: <ffff810150223e38>, it_real_fn, S:01
 # expires at 3635317355388 nsecs [in 3321751425029 nsecs]
 #5: <ffff810150223e38>, it_real_fn, S:01
 # expires at 3635630194993 nsecs [in 3322064264634 nsecs]

cpu: 1
 clock 0:
  .index:      0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .index:      1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
active timers:

cpu: 2
 clock 0:
  .index:      0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .index:      1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
active timers:

cpu: 3
 clock 0:
  .index:      0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
active timers:
 clock 1:
  .index:      1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
active timers:
 #0: <ffff810150223e38>, it_real_fn, S:01
 # expires at 313558625026 nsecs [in -7305333 nsecs]
 #1: <ffff810150223e38>, hrtimer_wakeup, S:01
 # expires at 369334850252 nsecs [in 55768919893 nsecs]
 #2: <ffff810150223e38>, it_real_fn, S:01
 # expires at 3936979059363 nsecs [in 3623413129004 nsecs]


Tick Device: mode:     0
Clock Event Device: hpet
 max_delta_ns:   85899346200
 min_delta_ns:   1920
 mult:           107374182
 shift:          32
 mode:           2
 next_event:     9223372036854775807 nsecs
 set_next_event: hpet_next_event
 set_mode:       hpet_set_mode
 event_handler:  tick_handle_periodic_broadcast
tick_broadcast_mask: 00000001


Tick Device: mode:     0
Clock Event Device: lapic
 max_delta_ns:   671088687
 min_delta_ns:   1200
 mult:           53687081
 shift:          32
 mode:           1
 next_event:     0 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  tick_handle_periodic

Tick Device: mode:     0
Clock Event Device: lapic
 max_delta_ns:   671088687
 min_delta_ns:   1200
 mult:           53687081
 shift:          32
 mode:           2
 next_event:     0 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  tick_handle_periodic

Tick Device: mode:     0
Clock Event Device: lapic
 max_delta_ns:   671088687
 min_delta_ns:   1200
 mult:           53687081
 shift:          32
 mode:           2
 next_event:     0 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  tick_handle_periodic

Tick Device: mode:     0
Clock Event Device: lapic
 max_delta_ns:   671088687
 min_delta_ns:   1200
 mult:           53687081
 shift:          32
 mode:           2
 next_event:     0 nsecs
 set_next_event: lapic_next_event
 set_mode:       lapic_timer_setup
 event_handler:  tick_handle_periodic


[chrisw@localhost ~]$ grep -e 0: -e LOC: /proc/interrupts 
  0:         72          2         58      36008   IO-APIC-edge      timer
LOC:      36655      36772      36725      36683 
[chrisw@localhost ~]$ grep -e 0: -e LOC: /proc/interrupts 
  0:         72          2         58      36165   IO-APIC-edge      timer
LOC:      36812      36929      36882      36840 
[chrisw@localhost ~]$ grep -e 0: -e LOC: /proc/interrupts 
  0:         72          2         58      36297   IO-APIC-edge      timer
LOC:      36944      37061      37014      36972 
[chrisw@localhost ~]$ grep -e 0: -e LOC: /proc/interrupts 
  0:         72          2         58      36424   IO-APIC-edge      timer
LOC:      37071      37188      37141      37099 

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

On Tue, 2007-05-08 at 03:06 -0700, Chris Wright wrote:

> Tick Device: mode:     0
> Clock Event Device: hpet
>  max_delta_ns:   85899346200
>  min_delta_ns:   1920
>  mult:           107374182
>  shift:          32
>  mode:           2
>  next_event:     9223372036854775807 nsecs
>  set_next_event: hpet_next_event
>  set_mode:       hpet_set_mode
>  event_handler:  tick_handle_periodic_broadcast
> tick_broadcast_mask: 00000001

Broadcasting is active. The system has C2 state, right ?

If it's not AMD you can add lapic_timer_c2_ok to the commandline.

	tglx

RE: [PATCH] x86-64 highres/dyntick support

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Chris Wright [mailto:chrisw@sous-sol.org] 
>Sent: Tuesday, May 08, 2007 2:52 AM
>To: Thomas Gleixner
>Cc: Chris Wright; LKML; Pallipadi, Venkatesh; john stultz; 
>Ingo Molnar; Arjan van de Ven; Steven Rostedt; Andi Kleen; 
>Andrew Morton
>Subject: Re: [PATCH] x86-64 highres/dyntick support
>
>* Thomas Gleixner (tglx@linutronix.de) wrote:
>> On Tue, 2007-05-08 at 02:39 -0700, Chris Wright wrote:
>> 
>> > OK, looks very similar all things considered.  One thing I 
>didn't do
>> > was fix lapic timer calibration (was hoping you'd do that 
>part, and you
>> > did ;-)  I've noticed that something has changed and I'm 
>seeing irq0
>> > handled on cpu3 (4 cpu system), where it used to be on 
>cpu0 as expected.
>> 
>> Strange, irq balancing ?
>
>That's what I was wondering, although i have same setup for 32-bit
>and it behaves as expected with cpu0 taking hpet or pit on irq0
>and lapic timer picked up on the other 3 cpus.
>

Yes. Looks like irq balancing issue. On i386 I see irq has flag
IRQF_NOBALANCING, but x86-64 does not have this flag. Can you add that
and check whether that makes any difference.

Thanks,
Venki

Re: [PATCH] x86-64 highres/dyntick support

[Nicolas Mailhot]

Le lundi 07 mai 2007 à 17:28 +0200, Thomas Gleixner a écrit :
> On Mon, 2007-05-07 at 09:16 +0000, Nicolas Mailhot wrote:
> > Thomas Gleixner <tglx <at> linutronix.de> writes:
> > 
> > > 
> > > I'm pleased to announce the first cut of the final x86_64
> > > highres/dyntick support, which I did based on Chris Wright's patch set,
> > > which is again based on Arjan van de Ven's initial work:
> > 
> > Do you have a 2.6.21-mm1 patchset?
> 
> Not yet, but it should be halfways easy to do one. Stay tuned.

Ok, tuning now

Thanks

-- 
Nicolas Mailhot

Re: [PATCH] x86-64 highres/dyntick support

[Alistair John Strachan]

On Sunday 06 May 2007 21:58:47 Thomas Gleixner wrote:
> I'm pleased to announce the first cut of the final x86_64
> highres/dyntick support, which I did based on Chris Wright's patch set,
> which is again based on Arjan van de Ven's initial work:

I've noticed a few problems with this patch series, which I manually (without 
difficulty) ported to 2.6.22-rc1.

Firstly, the output of /proc/interrupts looks a bit strange. NO_HZ isn't 
enabled, just high resolution timers. HZ was set to 1000.

alistair@damocles:~$ cat /proc/interrupts
           CPU0       CPU1
  0:        195          0   IO-APIC-edge      timer
  1:         21      13698   IO-APIC-edge      i8042
  8:          0          0   IO-APIC-edge      rtc
  9:          0          0   IO-APIC-fasteoi   acpi
 14:        117      51178   IO-APIC-edge      libata
 15:          0          0   IO-APIC-edge      libata
 18:        455     449373   IO-APIC-fasteoi   lan-sky, EMU10K1
 19:          0          3   IO-APIC-fasteoi   yenta, ohci1394
 20:        220      86188   IO-APIC-fasteoi   ohci_hcd:usb2
 21:          0         26   IO-APIC-fasteoi   ehci_hcd:usb1
 22:          0        273   IO-APIC-fasteoi   sata_nv
 23:        928     507781   IO-APIC-fasteoi   sata_nv, lan
NMI:          0          0
LOC:    4723272    4797930
ERR:          0

Only 195 timer interrupts? I only see this on an AMD Opteron, it doesn't occur 
on an Intel Core 2 Duo. Mainline reports this counter regularly increasing 
with or without the acpi_pm clocksource loaded.

Secondly, /proc/cpuinfo seems to be broken:

alistair@damocles:~$ cat /proc/cpuinfo | grep MHz
cpu MHz         : 210779.550
cpu MHz         : 210779.550

Unless my CPU is just under 80 times faster than it used to be, these numbers 
are incorrect. I expect 2700.50, or something similar. cpufreq isn't compiled 
in.

Finally, and possibly related, the dmesg timestamps seem to be totally broken. 
Apparently my machine booted in less than 1 second, with the last messages 
as:

[    0.607862] bridge: topology change detected, propagating
[    0.607862] bridge: port 2(lan-sky) entering forwarding state
[    0.830472] Linux agpgart interface v0.102 (c) Dave Jones

Of course, all of these problems might be PEBKAC, but I'm sceptical.

Find the kernel config, updated patch (for 2.6.22-rc1), dmesg, contents 
of /proc/interrupts and /proc/cpuinfo here:

http://devzero.co.uk/~alistair/2.6.22-rc1-hrt/

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.

Re: [PATCH] x86-64 highres/dyntick support

[Thomas Gleixner]

Alistair,

On Mon, 2007-05-14 at 02:17 +0100, Alistair John Strachan wrote:
> I've noticed a few problems with this patch series, which I manually (without 
> difficulty) ported to 2.6.22-rc1.

There are a couple of fixups pending. I'm going to push out a new queue
today.

> Only 195 timer interrupts? I only see this on an AMD Opteron, it doesn't occur 
> on an Intel Core 2 Duo. Mainline reports this counter regularly increasing 
> with or without the acpi_pm clocksource loaded.

We stop the PIT when we switch to the local APICs. On your Intel box you
might have deeper C-states which switch the system back to broadcast
mode via PIT.

> Secondly, /proc/cpuinfo seems to be broken:
> 
> alistair@damocles:~$ cat /proc/cpuinfo | grep MHz
> cpu MHz         : 210779.550
> cpu MHz         : 210779.550
> 
> Unless my CPU is just under 80 times faster than it used to be, these numbers 
> are incorrect. I expect 2700.50, or something similar. cpufreq isn't compiled 
> in.

Hmm. It seems the new TSC calibration routine is hosed.

> Finally, and possibly related, the dmesg timestamps seem to be totally broken. 
> Apparently my machine booted in less than 1 second, with the last messages 
> as:
> 
> [    0.607862] bridge: topology change detected, propagating
> [    0.607862] bridge: port 2(lan-sky) entering forwarding state
> [    0.830472] Linux agpgart interface v0.102 (c) Dave Jones

Hey, you have a really fast box :)

	tglx