X86_PM_TIMER: /proc/cpuinfo doesn't get updated

DISCUSSION Peter Chubb 5 participants 6 messages Mar 17, 2004 – Mar 18, 2004 3 messages not in the archive ACPI

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Peter Chubb

author

2004-03-17 01:33 UTC #2 lore raw

Quoted 1 line

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Dmitry" == Dmitry Torokhov <[email protected]> writes:

Quoted 8 lines · Karol Kozimor

Quoted 8 lines
Thus wrote john stultz: > Hmm. This is untested, but I think this should do the trick.
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with the patch cpu MHz value seems correct (both using acpi.ko and speedstep-ich.ko, but the bogomips is still at its initial value. Best regards,

Dmitry> Karol, do you have a P4? AFAIK P4's TSC is stable even if core Dmitry> frequence changes so loop_per_juffy (== bogomips) need not be Dmitry> updated.

The TSC is variable rate for Pentium-IV if you're using clock modulation.

Peter C

-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

A message that is not in the archive (sent off-list or not yet received): [email protected]

Dominik Brodowski

2004-03-17 09:53 UTC #4 lore raw

Quoted 20 lines · Dmitry Torokhov

Quoted 19 lines · Peter Chubb
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Dmitry" == Dmitry Torokhov <[email protected]> writes:
Quoted 8 lines · Karol Kozimor
Quoted 8 lines
Thus wrote john stultz: > Hmm. This is untested, but I think this should do the trick.
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with the patch cpu MHz value seems correct (both using acpi.ko and speedstep-ich.ko, but the bogomips is still at its initial value. Best regards,
Dmitry> Karol, do you have a P4? AFAIK P4's TSC is stable even if core Dmitry> frequence changes so loop_per_juffy (== bogomips) need not be Dmitry> updated.
The TSC is variable rate for Pentium-IV if you're using clock modulation.

Quoted 7 lines

Quoted 2 lines
Peter C
I understand that by clock modulation you mean throttling as opposed to true SpeedStep... OK, that means that for P4+ we somehow need to figure out whether the CPU is throttled or not to correctly calculate delays. Is there a clean way to get this data?

Hm, will have one patch to test it ready later today -- and a basic patch to do this distinction is in the hiding of my notebook's harddisk already... who's willing to do some testing on his SpeedStep-capable Pentium 4 - Mobile.

Dominik

Nate Lawson

2004-03-17 22:56 UTC #5 lore raw

Quoted 24 lines · Dominik Brodowski

Quoted 23 lines · Dmitry Torokhov
Quoted 21 lines · Peter Chubb
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Dmitry" == Dmitry Torokhov <[email protected]> writes:
Quoted 8 lines · Karol Kozimor
Quoted 8 lines
Thus wrote john stultz: > Hmm. This is untested, but I think this should do the trick.
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with the patch cpu MHz value seems correct (both using acpi.ko and speedstep-ich.ko, but the bogomips is still at its initial value. Best regards,
Dmitry> Karol, do you have a P4? AFAIK P4's TSC is stable even if core Dmitry> frequence changes so loop_per_juffy (== bogomips) need not be Dmitry> updated.
The TSC is variable rate for Pentium-IV if you're using clock modulation.
Peter C

Quoted 8 lines

Quoted 4 lines
I understand that by clock modulation you mean throttling as opposed to true SpeedStep... OK, that means that for P4+ we somehow need to figure out whether the CPU is throttled or not to correctly calculate delays. Is there a clean way to get this data?
Hm, will have one patch to test it ready later today -- and a basic patch to do this distinction is in the hiding of my notebook's harddisk already... who's willing to do some testing on his SpeedStep-capable Pentium 4 - Mobile.

Instead of all this gymnastics, how about:

1. If using Px states, state is unknown until first "set" event.

2. Implement priorities for time source selection and a generic timer API. This gets around the need to get the clock rate correct to have system timers work. On FreeBSD, this is /sys/kern/kern_tc.c

-Nate

Dominik Brodowski

2004-03-18 08:51 UTC #6 lore raw

Quoted 30 lines · Nate Lawson

Quoted 29 lines · Dominik Brodowski
Quoted 27 lines · Dmitry Torokhov
Quoted 12 lines · Peter Chubb
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Dmitry" == Dmitry Torokhov <[email protected]> writes:
Quoted 8 lines · Karol Kozimor
Quoted 8 lines
Thus wrote john stultz: > Hmm. This is untested, but I think this should do the trick.
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with the patch cpu MHz value seems correct (both using acpi.ko and speedstep-ich.ko, but the bogomips is still at its initial value. Best regards,
Quoted 9 lines
Dmitry> Karol, do you have a P4? AFAIK P4's TSC is stable even if core Dmitry> frequence changes so loop_per_juffy (== bogomips) need not be Dmitry> updated.
The TSC is variable rate for Pentium-IV if you're using clock modulation.
Peter C
I understand that by clock modulation you mean throttling as opposed to true SpeedStep... OK, that means that for P4+ we somehow need to figure out whether the CPU is throttled or not to correctly calculate delays. Is there a clean way to get this data?

Quoted 5 lines

Quoted 3 lines
Hm, will have one patch to test it ready later today -- and a basic patch to do this distinction is in the hiding of my notebook's harddisk already... who's willing to do some testing on his SpeedStep-capable Pentium 4 - Mobile.
Instead of all this gymnastics, how about:

It's not so much gymnastics -- implementing different handling for cpufreq drivers which do not affect the TSC is easy. It's just difficult to get to know what drivers/CPUs are affected... and the test run you did yesterday helped in evaluating this. Thanks for doing so.

Quoted 1 line

1. If using Px states, state is unknown until first "set" event.

Normally, when using cpufreq drivers the original state is known -- only the ACPI spec has this severe flaw, but there are tries for a workaround [patch is submitted]

Quoted 3 lines

2. Implement priorities for time source selection and a generic timer API. This gets around the need to get the clock rate correct to have system timers work. On FreeBSD, this is /sys/kern/kern_tc.c

IIRC, John Stultz intends to do a major upgrade of the timing code in 2.7.

Dominik

john stultz

2004-03-18 21:05 UTC #7 lore raw

Quoted 14 lines · Dominik Brodowski

Quoted 1 line · Nate Lawson
Instead of all this gymnastics, how about:
It's not so much gymnastics -- implementing different handling for cpufreq drivers which do not affect the TSC is easy. It's just difficult to get to know what drivers/CPUs are affected... and the test run you did yesterday helped in evaluating this. Thanks for doing so.
Quoted 1 line
1. If using Px states, state is unknown until first "set" event.
Normally, when using cpufreq drivers the original state is known -- only the ACPI spec has this severe flaw, but there are tries for a workaround [patch is submitted]

Quoted 5 lines

Quoted 3 lines
2. Implement priorities for time source selection and a generic timer API. This gets around the need to get the clock rate correct to have system timers work. On FreeBSD, this is /sys/kern/kern_tc.c
IIRC, John Stultz intends to do a major upgrade of the timing code in 2.7.

Well, we already have time source selection in 2.6 for i386. Most other arches have a single stable time source, so its not as critical for them. As for 2.7, a couple of holes have been poked in my initial design, so any major rewrite is somewhat on hold. Moving more arches to the more generic time_interpolator interface that ia64 uses may be the best solution, although its not as clean as I'd really like.

thanks
-john

Karol Kozimor

2004-03-17 10:00 UTC #8 lore raw

In reply to Peter Chubb

Thus wrote Peter Chubb:

Quoted 8 lines

Quoted 3 lines
Quoted 3 lines
Hmm... without the patch, neither cpu MHz nor bogomips are updated, with the patch cpu MHz value seems correct (both using acpi.ko and speedstep-ich.ko, but the bogomips is still at its initial value.
Dmitry> Karol, do you have a P4? AFAIK P4's TSC is stable even if core Dmitry> frequence changes so loop_per_juffy (== bogomips) need not be Dmitry> updated.
The TSC is variable rate for Pentium-IV if you're using clock modulation.

Yes, the machine in question does have a P4-M. Note also that the ACPI throttling interface (processor.ko, I believe) doesn't update the bogomips either.
Best regards,

Signature · 9 lines

Karol 'sziwan' Kozimor
sziwan-DETuoxkZsSqrDJvtcaxF/[email protected]


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click