Raj, Ashok wrote:
>>>> the processor topology before we start setting processor speeds. We
>>>> need to understand the processor dependencies (i.e, which processors
>>>> have a dependency on one another and what kind of dependency exists
>>>> between them) before we start setting/changing speeds. We get this
>>>> information from ACPI as each processor instance attaches. Once all
>>>>
> the
>
>>>> processors have attached, we have the necessary information we need
>>>>
> and
>
>>>> we initialize the speed.
>>>>
>>>>
>>> If you are using _PSD to track dependencies, and lets say the FMA
>>> decided to take a logical cpu offline.
>>>
>>> How do we manage p-state transitions after a dependent cpu goes
>>>
> offline?
>
>>>
>> Once a processor is offlined, then it's considered 100% "idle" from the
>> CPU driver perspective. The result is that dependent processors are
>>
> free
>
>> to make transition decisions on their own.
>>
>
> Don't you have to run the control method via using a wrmsr/io port
> write? So the thread has to run on the cpu.
>
> Typically if you have a set of cpus dependent you would do
>
> For each cpu in depend list
> Schedule this control thread on that cpu
> Perform write
> End
>
> Requires that for each change, you would need to touch the msr for each
> dependent cpu?
>
Yes you do have to touch the MSR on each CPU. And we do a cross-call on
the offlined processor to write the MSR. I believe that offlining a
processor prevents a thread from being scheduled on the processor, but I
don't think that it disables cross-calls . We've never seen a problem
with this in the functional test that we have that tests the offlined
processor case. But then again, there hasn't been anything really wrong
with the processor. I'd assume that if there was really something wrong
with the processor, then we would might fail the transition - which
would result in disabling power transitions for all dependent processors.
