Bill Holler wrote:
> Dana H. Myers wrote:
>
>> Bill Holler wrote:
>>
>>> Hi Aubrey,
>>>
>>> I suspect we should raise the interrupt priority level high enough
>>> for mutex_enter() to treat AcpiGbl_HardwareLock as a spin lock.
>>>
> I was thinking of something else. Raising the spl will not help.
>
>
>
>>> AcpiGbl_HardwareLock is declared as an ACPI_SPINLOCK.
>>> AcpiOsCreateLock() initializes AcpiGbl_HardwareLock as a
>>> MUTEX_DRIVER. The mutex must be an ADAPTIVE lock.
>>>
>>>
>>> What is the idle code doing with interrupts while it places the
>>> cpu into deeper c-states with the ACPI interface?
>>> I assume it will be like the current cpu_halt() function masks
>>> interrupts before halting the processor?
>>>
>>>
>> I'd like to understand better the exposure here. It's true
>> that AcpiOsCreateLock() uses adaptive mutexes; this hasn't
>> appeared to present a problem in the past and I'd like
>> to understand the specific cases where a spin mutex
>> is truly required. Perhaps the problem is better addressed
>> at a higher algorithmic level, for example.
>>
>
> The ACPI interfaces need to be used to halt the processor into
> ACPI C2 and C3. The idle thread cannot block on a mutex
> because the idle thread must always be dispatch-able.
> It would be much simpler if the idle thread can use the ACPI
> interface instead of alternatives such as creating a new block-able
> thread to do this.
>
> AcpiGbl_HardwareLock is defined as an ACPI_"SPIN"LOCK. :-)
> On the other hand, changing AcpiGbl_HardwareLock does
> sound risky.
>
>
Oh, of course. The thread in deep C-state will go to sleep holding
the mutex. Doh. How does Linux deal with this? Is a spinlock
CPU-local?
