Bill Holler wrote:
> Li, Aubrey wrote:
>
>> Dana.Myers wrote:
>>
>>
>>
>>> Li, Aubrey wrote:
>>>
>>>
>>>> Dana.Myers wrote:
>>>>
>>>>
>>>>
>>>>> Let's take a step back here and think about what we really
>>>>> want to happen.
>>>>>
>>>>> Cx is controlled using P_BLK registers, which are a per-CPU
>>>>> hardware resource; is it correct to assume that manipulation of
>>>>> a P_BLK is always done on the corresponding CPU? Another way of
>>>>> stating this - is it correct to assume that a P_BLK is never
>>>>> manipulated by another CPU?
>>>>>
>>>>>
>>>> No, we are not talking about P_BLK, we are talking about BM_STS in
>>>> PM1 Status Registers, which is not a per-CPU hardware resource, and
>>>> BM_RLD as well.
>>>>
>>>>
>>>>
>>> Ah, well. Something seems wrong with a thread holding a machine
>>> global lock on machine global resources on a CPU that's not executing
>>> - while other CPUs may contend for that same lock. Help me
>>> understand the use-case and why this isn't bad.
>>>
>>>
>> The problem is, currently we are using adaptive mutex for this global
>> lock,
>> and we are in idle thread. So one cpu hold this lock, and another cpu
>> has
>> to wait. We can keep spinning here, and we also can put this cpu's
>> thread to
>> sleep. Here, we are not spinning here, we are trying to put this thread
>> to sleep.
>> But, this is idle thread, it can't be put to sleep.
>>
>>
>
> To be clear: the BM_STS and PM1 status register access does
> halt the CPU. The CPU does not halt holding the lock.
>
> Bill
>
>
I'm confused. Is the CPU holding the hardware global lock when it
accesses the PM1 status (BM_STS) register? Is the access to the
register what causes the CPU to be halted?
