Li, Aubrey wrote:
> Dana.Myers 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.
>>>
>>>
>> Do I understand correctly that one CPU holds the hardware global lock
>> and then halts in a C2/C3 state?
>>
>> Dana
>>
>
>
> No, no, no.
> Let me write a piece of pseudo code.
>
> 1. acquire a global lock
> 2. read BM_STS
> 3. release the global lock
> 4. depending on the value of BM_STS to determine the next idle type
> 5. read P_LVLx/_CST to halt CPU. (put CPU to halt in C2/C3)
>
> Hope this is more clear.
>
This is actually the sort of code I expected. So - if I recall
correctly, the
problem that Bill described was that the CPU halting is taking place by
the idle thread, which isn't allowed to block on a mutex. So how
does changing the mutex type to spinlock solve this? Even a spinlock
could potentially halt.
