svn commit: r326383 - head/sys/x86/cpufreq

[Andriy Gapon]

On 30/11/2017 22:47, Jung-uk Kim wrote:
> On 11/30/2017 15:31, Conrad Meyer wrote:
>> On Thu, Nov 30, 2017 at 12:08 PM, Jung-uk Kim <jkim at freebsd.org> wrote:
>>> On 11/30/2017 14:32, Conrad Meyer wrote:
>>>> Hi,
>>>>
>>>> I don't think this answers the second question about the conditional.
>>>> It seems like PCPU_GET() for the initial CPU should be pulled out of
>>>> the loop, which binds the thread to a different CPU every iteration.
>>>
>>> Ah, good catch.  I'll fix it soon.  Sorry.
>>
>> Thanks! :-)
>>
>>>> Also, as a side effect of disabling verification, you have fixed PR
>>>> 221621, 219213, and probably 218262.
>>>
>>> Probably.  However, I am just trying to fix my FX-8350 and A10-6800 and
>>> I don't have Zen processors to verify the MSRs are actually working on
>>> those CPUs.
>>
>> I have one, I can verify if needed (although the change looks good to
>> me).  On some Zen systems (including mine) it seems that the hardware
>> can successfully set a P-state, but will fail to read it back.  For me
>> it is P1 but other users have reported P0.  That's the root issue of
>> all of those PRs.  If reading back isn't required, maybe that's a
>> solution to the issue.
> 
> Reading back was not really necessary (aka "fire-and-forget").  However,
> we wanted to make sure all cores are in the same P-state before
> returning to the caller.  Back in the days, it wasn't a big deal because
> we only had few cores to deal with and never expected to see complex
> topologies such as the Threadripper, I guess. :-/

I have not revisited cpufreq in a long time, so I can say something silly.
But I think that we need to finally start being aware of power state
dependencies (ACPI _PSD).  I have an impression that a good share of the
problems was (perhaps still is) because we completely ignored that stuff.  I
mean that if a platform tells us that CPUs in a given domain would transition to
a certain state only after we instruct all of them to go to that state, then it
is wrong of us to expect that after instructing just one CPU it would
transition to that state.


-- 
Andriy Gapon