Bill.Holler wrote: > It looks like pm_lock is only acquired when p-state coordination > is CPU_ACPI_HW_ALL. Perhaps most test machines are not using > hardware all. I noticed one test machine allows the BIOS to > set all 3 coordination types. We need to ensure all 3 types get > tested. > HW_ALL should be the default setting. It's a better perf/power tradeoff option than the other two ones.
Per Eric's new p-state governors, I found the number of p-state transition is reduced too much. That may cause the lock not contended so far, That might be the reason why we didn't hit this issue, and it's good, :-) -Aubrey > > > On 02/06/09 14:45, bugzilla-daemon at defect.opensolaris.org wrote: >> http://defect.opensolaris.org/bz/show_bug.cgi?id=6449 >> >> Summary: holding an adaptive mutex across P-state change >> requests can be dangerous >> Classification: Development >> Product: power-mgmt >> Version: unspecified >> Platform: Other >> OS/Version: Solaris >> Status: ACCEPTED >> Severity: minor >> Priority: P2 >> Component: PAD >> AssignedTo: eric.saxe at sun.com >> ReportedBy: eric.saxe at sun.com >> CC: tesla-dev at opensolaris.org >> >> >> As part of making a power state transition (e.g. P-state transition), >> cpupm_state_change() grabs an adaptive lock in the >> cpupm_state_domains_t structure. Because this platform routine can >> be invoked out of dispatcher context (operating at DISP_LEVEL), it >> can not permitted to block...otherwise recursive dispatcher entry >> could happen, where the kernel would quickly panic. >> >> I'm actually fairly surprised we haven't hit this yet. Because these >> locks exist on a per power domain basis, it must be the case that >> the lock is fairly non-contended (which is very good). The events >> which initiate P-state transitions in event-mode are generated >> around atomically maintained thresholds, so this has probably >> serialized things enough so that we've been lucky. Nonetheless, this >> mutex should really be a MUTEX_SPIN type, since we cannot yield the >> CPU. >> >> Maintaining DISP_LEVEL while holding the mutex will be sufficient. >> Higher levels (that would block out receipt of X_CALL_HIPRI) xcalls >> would be dangerous, since we could lose a race getting the lock >> trying to send a xcall for a P-state change, but never allow the >> owner of the lock to proceed with dropping it should the owner be >> trying to xcall us simultaneously at X_CALL_HIPRI. >> >> > > _______________________________________________ > tesla-dev mailing list > tesla-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/tesla-dev
