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. Thanks, -Aubrey
