Bug 6634 - semaphore/mutex/spinlock optimization
Summary: semaphore/mutex/spinlock optimization
Status: CLOSED CODE_FIX
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Robert Moore
URL:
Keywords:
Depends on:
Blocks: 6612
  Show dependency tree
 
Reported: 2006-05-31 22:33 UTC by Len Brown
Modified: 2008-06-13 20:15 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.17
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Len Brown 2006-05-31 22:33:59 UTC
acpi_os_create_semaphore() almost always ask for
binary semaphores rather than counting semaphores.

Linux now has an optimized mutex implementation to
provide binary semaphores as mutexes.

While lighter weight, the mutex implementation shares
the properties of semaphores in that they can sleep
and thus must not be called from interrupt context.
Further, since they may sleep, they are most appropriate
for critical sections of duration longer than context
switch time.

Linux also provides spin locks, which are minimal overhead,
and can be called at interrupt context.  However, it is
forbidden to sleep while holding a spin lock.

It would be more optimal if the ACPICA/OSL interface allowed ACPICA
to take advantage of these different locks.  Note that it
will require more than recognizing use_count == 1 in
acpi_os_create_semaphore(), as the three locks have different
lock/unlock calling syntax, and different semantics in their
ability to sleep or not.

Note that if they are split out, that a non-Linux OS could still
implement them all using semaphores if they desired.
Comment 1 Len Brown 2006-05-31 22:46:06 UTC
Specific example (from bug #6612):
acpi_set_register() calls acpi_ut_acquire_mutex(ACPI_MTX_HARWARE)
which calls acpi_os_wait_semaphore().  Not only is the semaphore
over-kill for protecting a simple RMW to a register, but using it means
that acpi_set_register() (and acpi_clear_event() which calls it)
can not be called from interrupt context.

Looks like ACPI_MTX_HARDWARE should be implemented with a spin-lock
and accessed with spin_lock_irqsave()/spin_lock_irqrestore() --
the lowest overhead locking mechanism available in the kernel
asside from atomic memory accesses themselves.

Comment 2 Robert Moore 2006-06-01 14:25:01 UTC
We already have separate spin lock OSL interfaces:

acpiosxf.h(215):AcpiOsCreateLock (
acpiosxf.h(219):AcpiOsDeleteLock (
acpiosxf.h(223):AcpiOsAcquireLock (
acpiosxf.h(227):AcpiOsReleaseLock (

And semaphores/mutexes are very similar since a mutex is essentially a special 
case semaphore.
Comment 3 Robert Moore 2006-06-02 15:49:24 UTC
First step will be to use a spinlock instead of a mutex for the ACPI hardware 
lock.
Comment 4 Len Brown 2006-06-15 20:02:05 UTC
step mentioned in comment #3 shipped in ACPICA 20060608, 
which is integrated into the linux acpi-test tree. 
 
ACPI_MTX_HARDWARE (a semaphore) is replaced by 
acpi_gbl_hardware_lock (a spin-lock) 
 
Comment 5 Robert Moore 2006-06-26 14:55:32 UTC
For ACPICA 20060623, deployed the ACPI_SPINLOCK type for the OSL lock 
interfaces, and implemented the first pass at new Mutex OSL interfaces. These 
are defined as macros that map them to the existing semaphore interfaces for 
the time being, the macros will go away in a future release.

Linux needs a timed-wait mutex acquire interface before ACPICA can use the 
Linux mutex object.
Comment 6 Zhang Rui 2008-03-18 00:06:04 UTC
Bob, what's the status of this bug? :)
Comment 7 Len Brown 2008-03-25 21:02:00 UTC
> Linux needs a timed-wait mutex acquire interface before ACPICA can use the 
> Linux mutex object.

Matthew Wilcox has proposed a solution:

[PATCH 5/6] Add down_timeout and change ACPI to use it

http://lkml.org/lkml/2008/3/14/309
Comment 8 Len Brown 2008-06-13 20:15:43 UTC
shipped in linux-2.6.26-rc1 -- closed.

commit f1241c87a16c4fe9f4f51d6ed3589f031c505e8d
Author: Matthew Wilcox <matthew@wil.cx>
Date:   Fri Mar 14 13:43:13 2008 -0400

    Add down_timeout and change ACPI to use it

Note You need to log in before you can comment on or make changes to this bug.