Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Karol Kozimor]

Thus wrote Daniele Venzano:
> > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > issue seems cosmetic only, CPU frequency changes (watching
> > temperature/battery life).
> I can confirm, I'm seeing the same behavior. Please note that the
> bogomips count gets updated, it's only the frequency that doesn't
> change.

Same here with a P4-M, follow-up to John and Dmitry.
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dmitry Torokhov]

On Tuesday 16 March 2004 04:42 pm, Karol Kozimor wrote:
> Thus wrote Daniele Venzano:
> > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > issue seems cosmetic only, CPU frequency changes (watching
> > > temperature/battery life).
> > I can confirm, I'm seeing the same behavior. Please note that the
> > bogomips count gets updated, it's only the frequency that doesn't
> > change.
> 
> Same here with a P4-M, follow-up to John and Dmitry.
> Best regards,
> 

PM timer does not install CPUFREQ handler which would scale cpu_khz to
give proper display. I might cook up something later tonight.

-- 
Dmitry

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[john stultz]

On Tue, 2004-03-16 at 13:42, Karol Kozimor wrote:
> Thus wrote Daniele Venzano:
> > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > issue seems cosmetic only, CPU frequency changes (watching
> > > temperature/battery life).
> > I can confirm, I'm seeing the same behavior. Please note that the
> > bogomips count gets updated, it's only the frequency that doesn't
> > change.
> 
> Same here with a P4-M, follow-up to John and Dmitry.

Hmm. This is untested, but I think this should do the trick.

Dominik: Is there any reason I'm not seeing why cpu_khz should only be
updated when using the TSC?

thanks
-john

===== arch/i386/kernel/timers/timer_tsc.c 1.36 vs edited =====
--- 1.36/arch/i386/kernel/timers/timer_tsc.c	Tue Feb  3 21:35:49 2004
+++ edited/arch/i386/kernel/timers/timer_tsc.c	Tue Mar 16 15:23:49 2004
@@ -360,8 +360,8 @@
 		if (variable_tsc)
 			cpu_data[freq->cpu].loops_per_jiffy = cpufreq_scale(loops_per_jiffy_ref, ref_freq, freq->new);
 #ifndef CONFIG_SMP
+		cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
 		if (use_tsc) {
-			cpu_khz = cpufreq_scale(cpu_khz_ref, ref_freq, freq->new);
 			if (variable_tsc) {
 				fast_gettimeoffset_quotient = cpufreq_scale(fast_gettimeoffset_ref, freq->new, ref_freq);
 				set_cyc2ns_scale(cpu_khz/1000);

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[john stultz]

On Tue, 2004-03-16 at 15:19, Dmitry Torokhov wrote:
> On Tuesday 16 March 2004 04:42 pm, Karol Kozimor wrote:
> > Thus wrote Daniele Venzano:
> > > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > > issue seems cosmetic only, CPU frequency changes (watching
> > > > temperature/battery life).
> > > I can confirm, I'm seeing the same behavior. Please note that the
> > > bogomips count gets updated, it's only the frequency that doesn't
> > > change.
> > 
> > Same here with a P4-M, follow-up to John and Dmitry.
> > Best regards,
> > 
> 
> PM timer does not install CPUFREQ handler which would scale cpu_khz to
> give proper display. I might cook up something later tonight.

Actually, the cpufreq handler is installed by an initcall regardless of
which time-source is used. However as the handler changes a few TSC
specific variables, it exits in timer_tsc.c.

I think the fix I just mailed should do the trick. Let me know if it
doesn't.

thanks
-john

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Tue, Mar 16, 2004 at 03:28:15PM -0800, john stultz wrote:
> On Tue, 2004-03-16 at 13:42, Karol Kozimor wrote:
> > Thus wrote Daniele Venzano:
> > > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > > issue seems cosmetic only, CPU frequency changes (watching
> > > > temperature/battery life).
> > > I can confirm, I'm seeing the same behavior. Please note that the
> > > bogomips count gets updated, it's only the frequency that doesn't
> > > change.
> > 
> > Same here with a P4-M, follow-up to John and Dmitry.
> 
> Hmm. This is untested, but I think this should do the trick.
> 
> Dominik: Is there any reason I'm not seeing why cpu_khz should only be
> updated when using the TSC?

Is cpu_khz always correct (or, at least, nonzero) when we're reaching this 
code path?

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Karol Kozimor]

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,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dmitry Torokhov]

On Tuesday 16 March 2004 06:32 pm, john stultz wrote:
> On Tue, 2004-03-16 at 15:19, Dmitry Torokhov wrote:
> > PM timer does not install CPUFREQ handler which would scale cpu_khz to
> > give proper display. I might cook up something later tonight.
> 
> Actually, the cpufreq handler is installed by an initcall regardless of
> which time-source is used. However as the handler changes a few TSC
> specific variables, it exits in timer_tsc.c.
>

Yes, you are of course right, I missed that fact, sorry.

-- 
Dmitry

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dmitry Torokhov]

On Tuesday 16 March 2004 07:13 pm, Karol Kozimor wrote:
> 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,
> 

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

-- 
Dmitry

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

On Tue, Mar 16, 2004 at 04:46:54PM -0800, john stultz wrote:
> On Tue, 2004-03-16 at 15:33, Dominik Brodowski wrote:
> > On Tue, Mar 16, 2004 at 03:28:15PM -0800, john stultz wrote:
> > > On Tue, 2004-03-16 at 13:42, Karol Kozimor wrote:
> > > > Thus wrote Daniele Venzano:
> > > > > > I have a notebook with an Athlon-M CPU. I tried linux 2.6.4 with
> > > > > > CONFIG_X86_PM_TIMER=y and I noticed that /proc/cpuinfo doesn't get
> > > > > > updated when I switch frequency (via sysfs, using powernow-k7). The is
> > > > > > issue seems cosmetic only, CPU frequency changes (watching
> > > > > > temperature/battery life).
> > > > > I can confirm, I'm seeing the same behavior. Please note that the
> > > > > bogomips count gets updated, it's only the frequency that doesn't
> > > > > change.
> > > > 
> > > > Same here with a P4-M, follow-up to John and Dmitry.
> > > 
> > > Hmm. This is untested, but I think this should do the trick.
> > > 
> > > Dominik: Is there any reason I'm not seeing why cpu_khz should only be
> > > updated when using the TSC?
> > 
> > Is cpu_khz always correct (or, at least, nonzero) when we're reaching this 
> > code path?
> 
> Using the PIT time source, cpu_khz is zero, so maybe it should be
> conditional on if(cpu_khz)?

That will do the trick.

	Dominik

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

On Tue, Mar 16, 2004 at 11:40:57PM -0500, Dmitry Torokhov wrote:
> On Tuesday 16 March 2004 08:33 pm, Peter Chubb wrote:
> > >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
> > 
> > Dmitry> On Tuesday 16 March 2004 07:13 pm, Karol Kozimor wrote:
> > >> 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
> > 
> 
> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Karol Kozimor]

Thus wrote Peter Chubb:
> >> 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,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Nate Lawson]

On Wed, 17 Mar 2004, Dominik Brodowski wrote:
> On Tue, Mar 16, 2004 at 11:40:57PM -0500, Dmitry Torokhov wrote:
> > On Tuesday 16 March 2004 08:33 pm, Peter Chubb wrote:
> > > >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
> > >
> > > Dmitry> On Tuesday 16 March 2004 07:13 pm, Karol Kozimor wrote:
> > > >> 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
> > >
> >
> > 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

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[Dominik Brodowski]

[-- Attachment #1: Type: text/plain, Size: 2539 bytes --]

On Wed, Mar 17, 2004 at 02:56:27PM -0800, Nate Lawson wrote:
> On Wed, 17 Mar 2004, Dominik Brodowski wrote:
> > On Tue, Mar 16, 2004 at 11:40:57PM -0500, Dmitry Torokhov wrote:
> > > On Tuesday 16 March 2004 08:33 pm, Peter Chubb wrote:
> > > > >>>>> "Dmitry" == Dmitry Torokhov <dtor_core@ameritech.net> writes:
> > > >
> > > > Dmitry> On Tuesday 16 March 2004 07:13 pm, Karol Kozimor wrote:
> > > > >> 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
> > > >
> > >
> > > 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:

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.
 
> 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]

> 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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [ACPI] X86_PM_TIMER: /proc/cpuinfo doesn't get updated

[john stultz]

On Thu, 2004-03-18 at 00:51, Dominik Brodowski wrote:
> On Wed, Mar 17, 2004 at 02:56:27PM -0800, Nate Lawson wrote:
> > 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.
>  
> > 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]
> 
> > 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