Dana.Myers wrote: > 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.
It depends on what kind of block. Spinning is okay, put the thread to sleep is not allowable. Thanks, -Aubrey
