[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-commits-all
Subject:    Re: svn commit: r326383 - head/sys/x86/cpufreq
From:       Jung-uk Kim <jkim () FreeBSD ! org>
Date:       2017-11-30 20:47:24
Message-ID: 31ee136d-164e-bb9b-3a90-71bb7f55595a () FreeBSD ! org
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


On 11/30/2017 15:31, Conrad Meyer wrote:
> On Thu, Nov 30, 2017 at 12:08 PM, Jung-uk Kim <jkim@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. :-/

Jung-uk Kim


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]