Where to get the kext

[mercurysquad]

mercurysquad original version:

http://code.google.com/p/xnu-speedstep

 

Superhai mod:

http://www.superhai.com/darwin.html

(This mod might have better support for many CPUs, has inbuilt autothrottler, and a nice GUI. Currently no under-volting though).

[aliasa_anderson]

Seems to be working fine on Intel Core Duo T2050@1.6GHz.

No issues as of now.

 

EDIT:one found.

 

I see the kext loads too early while booting,so early that even the CPU initialization is not completed.Even tough it loads just fine and works perfectly after this.

 

 

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: IntelEnhancedSpeedStep: INFO Initializing version 1.4.9 © Prashant Vaibhav <xxxxxxxxxxxxxxxxx.com>

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: IntelEnhancedSpeedStep: WARN Holy moly we cannot find your CPU!

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: AppleACPICPU: ProcessorApicId=0 LocalApicId=0 Enabled

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: AppleACPICPU: ProcessorApicId=1 LocalApicId=1 Enabled

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: Loading security extension com.apple.security.TMSafetyNet

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: calling mpo_policy_init for TMSafetyNet

 

 

Mercurysquad,

 

do you plan to integrate P states with C states in future releases.

I mean if not deep C states atleast the C1 to just halt one or more cores down when load is low.

Also,will it be possible to add sysctl entries for cpu temperature? like Tj(Junction) and/or Ts(Sink) ?

 

 

I also had one query,

I see the target load parameter is now 40.

So does this mean P state transition takes place abruptly or there is some tolerance(or hysteresis like in Superhai's kext) involved.

[mercurysquad2]

Seems to be working fine on Intel Core Duo T2050@1.6GHz.

No issues as of now.

 

EDIT:one found.

 

I see the kext loads too early while booting,so early that even the CPU initialization is not completed.Even tough it loads just fine and works perfectly after this.

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: IntelEnhancedSpeedStep: INFO Initializing version 1.4.9 © Prashant Vaibhav <xxxxxxxxxxxxxxxxx.com>

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: IntelEnhancedSpeedStep: WARN Holy moly we cannot find your CPU!

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: AppleACPICPU: ProcessorApicId=0 LocalApicId=0 Enabled

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: AppleACPICPU: ProcessorApicId=1 LocalApicId=1 Enabled

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: Loading security extension com.apple.security.TMSafetyNet

Fri Jun 19 08:53:25 localhost kernel[0] <Debug>: calling mpo_policy_init for TMSafetyNet

Mercurysquad,

 

do you plan to integrate P states with C states in future releases.

I mean if not deep C states atleast the C1 to just halt one or more cores down when load is low.

Also,will it be possible to add sysctl entries for cpu temperature? like Tj(Junction) and/or Ts(Sink) ?

I also had one query,

I see the target load parameter is now 40.

So does this mean P state transition takes place abruptly or there is some tolerance(or hysteresis like in Superhai's kext) involved.

 

The kext loading too early is intentional, but I have added a waitForService(resourceMatching(IOCPU)) so that the auto-throttler and PState creation will wait up to 1 minute for the CPU service to be initialized. That's why the kext still works well. Though on my machine I don't get that message about not finding the CPU, so you should verify using sysctl that the freqs and voltages are appropriate for your CPU. It is entirely possible that the kext really can't find your CPU and is thus auto-creating the PState list.

 

As for C-states, yes maybe in the future I want to add that support. It's not immediately on the list, but it's definitely a "want-to-have".

 

The targetload was increased to 40 because I felt 30 was too low, and the CPU was switching up to higher freqs even on small load bursts of 40-50%. On my FreeBSD system, my CPU can throttle all the way down to 100 MHz and stays at 40-60% cpu usage, only throttling to higher freqs then usage goes above around 65-70%! I think I might change default target load to even higher, around 60% because going by the stats that v1.5.0 collects :

kern.cputhrottle_freqs: 800 1067 1333 1733 
kern.cputhrottle_usage: 82.0%  2.0%  2.0%  12.0%

 

You see that most of the time the CPU is either in the lowest or highest P-state, and this is most likely because once the cpu load in 800 mhz goes to 80%, which is 2x the target load, the throttler wants to make the frequency 2 times too, getting 1600 mhz as the optimal frequency, and thus choosing 1733 which is the closest one supported by the CPU. In other words, the kext tries to maintain 40% usage and in doing so, skips most of the intermediate pstates. I might tune the algorithm based on stats I receive from other users once 1.5.0 goes online.

 

Yes there is hysteresis built into the throttler too, since the very beginning, and I'm actually quite happy with the algorithm. In short, the kext chooses the most appropriate frequency and switches directly to it instead of switching in steps. After this, the throttler will stay on this frequency for a time period which is proportional to the chosen P-state (ie, it won't stay long on a high frequency but won't switch down too early either). But this initial 'sustain' period happens only just after switching. If the optimal P-state is found to be the same on the next check, throttler checks the load more often so it can switch back to a more appropriate p-state as soon as there is no need to operate at high frequency.

 

Actually it's tough to explain in words, just check the code here :

http://opensource.mercurysquad.com/xnu-spe...edSpeedStep.cpp

 

Line 828 and later (scroll the the very bottom).

[aliasa_anderson]

The kext loading too early is intentional, but I have added a waitForService(resourceMatching(IOCPU)) so that the auto-throttler and PState creation will wait up to 1 minute for the CPU service to be initialized. That's why the kext still works well. Though on my machine I don't get that message about not finding the CPU, so you should verify using sysctl that the freqs and voltages are appropriate for your CPU. It is entirely possible that the kext really can't find your CPU and is thus auto-creating the PState list.

 

As for C-states, yes maybe in the future I want to add that support. It's not immediately on the list, but it's definitely a "want-to-have".

 

Yes you are right,its auto creating the P States.

And good to hear that you have plans for C States.Well,i have already started reading the datasheets for processors,maybe i could help you with docs ,that may save some of your time.

 

I found that with your 1.4.0 kext on OSX 10.5.4,the pstate table was easily obtined from ACPI but since 10.5.5/10.5.6 update,i think Apple made some mods to ACPI_SMC_PlatformPlugin.kext.Because this kext seems to prevent your speedstep kext to get the pstates as i started observing "Error while getting P States" .It was at this time when i also started noticing

 

waitfor(ServiceMatching AppleIntelCPUPowermanagement.kext) timeout

 

from ACPI_SMC_PlatformPlugin.kext

 

Last but not the least,thanks alot for taking time to explain all the details.

 

Keep up the good work.

[mooquu]

thanks!!!