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 <[email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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
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