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.
Thanks,
-Aubrey
>
>
>
> Li, Aubrey wrote:
>> Dana.Myers wrote:
>>
>>> Li, Aubrey wrote:
>>>> I would suggest this following patch for this issue:
>>>> =====================================
>>>> diff -r cb29bc2e1e6e usr/src/uts/intel/io/acpica/osl.c
>>>> --- a/usr/src/uts/intel/io/acpica/osl.c Sun Jul 13 14:36:23 2008
>>>> -0700 +++ b/usr/src/uts/intel/io/acpica/osl.c Mon Jul 14
10:44:33
>>>> 2008 +0800 @@ -439,7 +439,7 @@ return
(AE_BAD_PARAMETER);
>>>> mp = (kmutex_t *)kmem_alloc(sizeof (kmutex_t), KM_SLEEP);
>>>> - mutex_init(mp, NULL, MUTEX_DRIVER, NULL);
>>>> + mutex_init(mp, NULL, MUTEX_SPIN, (void *)PIL_MAX);
>>>> *OutHandle = (ACPI_HANDLE)mp;
>>>> return (AE_OK);
>>>> =====================================
>>>>
>>>> Any thoughts?
>>>>
>>> Absolutely. I'm not yet certain what the semantics of a Linux
>>> spinlock are and whether the semantics of a Solaris mutex(...
>>> MUTEX_SPIN ...) truly match it.
>>>
>>> What are the semantics of a Linux spinlock? I'll take a look at
>>> this in the morning.
>>
>> If I understand correctly, spinlock is a very simple single-holder
>> lock, designed for multiprocessor and useless in UP environment. If
>> a process attempts to acquire a spinlock and it's unavailable, the
>> process will keep trying(spinning) until it can acquire the lock.
>>
>> Thanks,
>> -Aubrey
>>
>>> Cheers,
>>> Dana
>>>> Thanks,
>>>> -Aubrey
>>>>
>>>> Li, Aubrey wrote:
>>>>
>>>>
>>>>> Liu, Jiang wrote:
>>>>>
>>>>>
>>>>>> Hi Aubrey,
>>>>>> Currently solaris ACPICA OSL layer uses adaptive mutex to
>>>>>> implement ACPI Lock which seems not confirm to ACPICA programmer
>>>>>> manual. Please refer to Section 7.4.5 of "ACPI Component
>>>>>> Architecture Programmer Reference" as below:
>>>>>>
>>>>>> 7.4.5 AcpiOsCreateLock
>>>>>> Functional Description:
>>>>>> Create a spin lock. Spin locks are used in the ACPI CA subsystem
>>>>>> only when there is requirement for mutual exclusion on data
>>>>>> structures that are accessed by both interrupt handlers and
>>>>>> normal code.
>>>>>>
>>>>> Yeah, from ACPICA manual, hardware lock must a spin lock.
>>>>> Solaris OSL initialize it as MUTEX_DRIVER, which could be either
>>>>> MUTEX_ADAPTIVE or MUTEX_SPIN depending on the iblock cookie.
>>>>> Since iblock cookie is NULL for AcpiGbl_HardwareLock, so it's
>>>>> adaptive. I think it should be initialized as MUTEX_SPIN.
>>>>>
>>>>> Thanks,
>>>>> -Aubrey
>>>>>
>>>>>
>>>>>> Aubrey Li <> wrote:
>>>>>>
>>>>>>> On Sat, Jul 12, 2008 at 5:49 AM, Bill Holler
>>>>>>> <Bill.Holler at sun.com> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>> We need interrupts to be masked when the processor wakes
>>>>>>>>>> up, so we can fixup the local APIC state.
>>>>>>>>>>
>>>>>>>>> It sounds like there's a local CPU vs. other CPU issue
>>>>>>>>> with respect to masking interrupts then?
>>>>>>>>>
>>>>>>>> This is a related but different issue than the above idle
>>>>>>>> thread blocking in the ACPI interfaces.
>>>>>>>>
>>>>>>>> The current idle loop services interrupts from the HALT state
>>>>>>>> before continuing with the idle loop. CPUs in deep C-state
>>>>>>>> will have to execute some code to cleanup cpu state before
>>>>>>>> servicing interrupts.
>>>>>>>>
>>>>>>>> One option is to have the hardware return control to the idle
>>>>>>>> thread with interrupts masked. Another option is to check
>>>>>>>> for deep c-state cleanup in the interrupt path similar to
>>>>>>>> tlb_service().
>>>>>>>>
>>>>>>>>
>>>>>>> I think the issue might be different.
>>>>>>> The following is what idle code doing.
>>>>>>> cpu_acpi_idle()
>>>>>>> {
>>>>>>> value = AcpiGetRegister(); /* need a lock */
>>>>>>> using value to determine next idle type;
>>>>>>> cli();
>>>>>>> place the processor into Cx;
>>>>>>> sti();
>>>>>>> }
>>>>>>>
>>>>>>> The problem occurs in AcpiGetRegister(), it uses
>>>>>>> AcpiGbl_HardwareLock. I suspect AcpiGbl_HardwareLock really
>>>>>>> works as a spin lock. Otherwise it will not go into turnstiles
>>>>>>> block.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> -Aubrey
>>>>>>> _______________________________________________
>>>>>>> tesla-dev mailing list
>>>>>>> tesla-dev at opensolaris.org
>>>>>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>>>>>>
>>>>>> _______________________________________________
>>>>>> tesla-dev mailing list
>>>>>> tesla-dev at opensolaris.org
>>>>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>>>>>
>>>>> _______________________________________________
>>>>> tesla-dev mailing list
>>>>> tesla-dev at opensolaris.org
>>>>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
>>
>> _______________________________________________
>> tesla-dev mailing list
>> tesla-dev at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/tesla-dev
