PATCH - update TSC freq when cpufreq changes it

Attached is a patch that uses eventhandlers to update the
TSC freq.
This is important because DELAY() uses TSC directly (on i386
and amd64)
but the rate calculated at boot changes if cpufreq is in
use.

It maintains current behavior that cpufreq transitions are
denied if TSC
is the active timecounter.  The API is that there is a pre
and post
transition eventhandler that is called by the cpufreq core. 
The pre
handler is passed the next state (including freq, power,
etc.) and can
store a non-zero status value in the output arg to indicate
it wants to
reject the transition.  The post handler also is passed the
next state
and the result of the transition (0 on success).

Once any issues are addressed, I'll update this for amd64,
ALTQ, and
possibly PC98.  Non-x86 archs can stick with the current
behavior if
they're satisfied or hook the eventhandlers provided to
DTRT.

-- 
Nate

_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Tuesday 27 February 2007 23:16, Nate Lawson wrote:
> Attached is a patch that uses eventhandlers to update
the TSC freq.
> This is important because DELAY() uses TSC directly (on
i386 and amd64)
> but the rate calculated at boot changes if cpufreq is
in use.
>
> It maintains current behavior that cpufreq transitions
are denied if
> TSC is the active timecounter.  The API is that there
is a pre and post
> transition eventhandler that is called by the cpufreq
core.  The pre
> handler is passed the next state (including freq,
power, etc.) and can
> store a non-zero status value in the output arg to
indicate it wants to
> reject the transition.  The post handler also is passed
the next state
> and the result of the transition (0 on success).

Any reason for passing the result to the post handler in by
reference - 
other than being able to re-use the same function type as in
the pre 
handler?  API-wise this seems to be a mistake as one
consumer could mess 
up the result for the rest and the variable name
"error" in the INVOKE 
also suggests that this could be used to report back.

> Once any issues are addressed, I'll update this for
amd64, ALTQ, and
> possibly PC98.  Non-x86 archs can stick with the
current behavior if
> they're satisfied or hook the eventhandlers provided to
DTRT.

-- 
/"  Best regards,                      | mlaierfreebsd.org
 /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.l
ove2party.net/  | mlaierEFnet
/   ASCII Ribbon Campaign              | Against HTML Mail
and News

Max Laier wrote:
> On Tuesday 27 February 2007 23:16, Nate Lawson wrote:
>> Attached is a patch that uses eventhandlers to
update the TSC freq.
>> This is important because DELAY() uses TSC directly
(on i386 and amd64)
>> but the rate calculated at boot changes if cpufreq
is in use.
>>
>> It maintains current behavior that cpufreq
transitions are denied if
>> TSC is the active timecounter.  The API is that
there is a pre and post
>> transition eventhandler that is called by the
cpufreq core.  The pre
>> handler is passed the next state (including freq,
power, etc.) and can
>> store a non-zero status value in the output arg to
indicate it wants to
>> reject the transition.  The post handler also is
passed the next state
>> and the result of the transition (0 on success).
> 
> Any reason for passing the result to the post handler
in by reference - 
> other than being able to re-use the same function type
as in the pre 
> handler?  API-wise this seems to be a mistake as one
consumer could mess 
> up the result for the rest and the variable name
"error" in the INVOKE 
> also suggests that this could be used to report back.

Yes, the main gaol was to reuse the function.  Plus I
thought in the
future there might be some conceivable need to revoke a
change after it
had occurred ("oops! change right back!").  We
wouldn't need to change
an API to allow that.

Unless there's a real problem with it, I'd like to keep that
ability in
the API.  To make it clear though, I should probably assign
error to
some tmp var and pass that in to cpufreq_post_change
handlers so it has
no effect if the user overwrites it.

-- 
Nate
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

In message <45E4ADCD.4090909root.org>, Nate Lawson
writes:

>Attached is a patch that uses eventhandlers to update
the TSC freq.

Question:  are we at a point where the TSC-frequency
reported by ACPI
is more precise than our own ad-hoc calibrations ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phkFreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained
by incompetence.
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"