* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 16 Aug 2009, Ingo Molnar wrote:
> >
> > What's the current situation on s390, precisely which of the 28 lock
> > functions are a win to be inlined and which ones are a loss? Do you
> > have a list/table perhaps?
>
> Let's look at x86 instead.
>
> The one I can _guarantee_ is worth inlining is "spin_unlock()",
> since it just generates a single "incb %m" or whatever. [...]
We do that already for that reason:
/*
* We inline the unlock functions in the nondebug case:
*/
#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
!defined(CONFIG_SMP)
# define spin_unlock(lock) _spin_unlock(lock)
# define read_unlock(lock) _read_unlock(lock)
# define write_unlock(lock) _write_unlock(lock)
# define spin_unlock_irq(lock) _spin_unlock_irq(lock)
# define read_unlock_irq(lock) _read_unlock_irq(lock)
# define write_unlock_irq(lock) _write_unlock_irq(lock)
this works fine here:
ffffffff8103d359 <finish_task_switch>:
...
ffffffff8103d393: fe 03 incb (%rbx)
ffffffff8103d395: fb sti
that's an inlined spin_unlock_irq() in finish_task_switch().
We dont do this if DEBUG_SPINLOCK is defined (which bloats the
function) or if CONFIG_PREEMPT is defined.
Maybe the latter case could be revised although generally it's not
worth inlining functions that also touch task-struct / threadinfo.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
