Eric Saxe wrote:
> Mark Haywood wrote:
>> Eric Saxe wrote:
>>
>>> Alexander Kolbasov wrote:
>>>
>>>> I doscussed this with Eric, just wanted to have some online record.
>>>> Li> DTRACE_PROBE2(cpu_change_speed, processorid_t, cpudsp->cpu_id,
>>>> Li> uint_t, new_spd->speed);
>>>> Li> DTRACE_PROBE2(cpu_change_speed, processorid_t, cpudsp->cpu_id,
>>>> Li> uint_t, new_spd->speed);
>>>>
>>>> In generl it is not a good idea to dereference pointers in DTRACE SDT
>>>> probes since this will increase disabled probe effect. It is better to
>>>> provide raw pointers (preferably available on the stack already) and
>>>> then have translators defined that will defer pointer dereference to
>>>> the time when the probe is enabled.
>>> Aubrey was keen enough to point out that the "old speed" pointer
>>> (which I added) could be NULL, if the CPU has never undergone a CPU
>>> speed change. I was wondering if it would be possible to have the
>>> current speed initialized (perhaps at attach / initialization time)?
>>> That would save having to worry about having an uninitialized
>>> current speed throughout much of the code, including the DTrace
>>> probe / translator implementation.
>>>
>> The speed isn't initialized at attach time because we need to
>> understand the processor topology before we start setting processor
>> speeds.
>
> It makes sense having to know what the dependencies are before we
> change processor speeds. But what about just asking what the current
> speed is (not changing it) so that it can be initialized...or is there
> no way to ask, and we have to change it to know?
Unfortunately, I don't think that's doable. It's one of the few things
that I don't like about the way Intel implemented P-states. Reading the
status MSR will not allow you to determine your current P-state. I
believe you have to set it to be certain. I think that the same is true
of SPARC.
