[lkml]   [2004]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH][2.6] Completely out of line spinlocks / i386
On Wed, 11 Aug 2004 15:13:15 -0700 (PDT), Linus Torvalds wrote:
>> The inline spinlocks are _wonderful_ for seeing where the contention is in
>> a simple profile.
>> In contrast, in a profile the out-of-lines ones will show "x% was spent on
>> spinlocks". Which doesn't help much when you want to see where the problem
>> is.
>> This was _hugely_ useful, at least for me, for seeing what locks were
>> problematic.

On Thu, Aug 12, 2004 at 10:01:50AM +1000, Keith Owens wrote:
> Tweak the profile code to detect that the instruction pointer is in the
> out of line spinlock code and replace the ip with the caller's ip. We
> already do that for ia64, where the out of line spinlock code is a big
> win. A kdb backtrace on an ia64 contended lock will even decode the
> address of the lock, which is only possible because the lock address is
> in a known location for this case.

This would be a useful extension for other architectures also, if/when
they convert to doing likewise.

I actually favored making C language spin_lock() (i.e. the goddamn
thing is declared as a C function void spin_lock(spinlock_t *) and is
called like a normal C function -- no inline asm or inline C functions
at all) entrypoints beyond merely conslidating contention loops, but I
feared that would be too extreme of a reversal of the status quo to
ever get traction to post it. It did, however, shrink the kernel text
the most of any of the out-of-line spinlock patches by a large margin,
something completely absurd-sounding, like 220KB vs. 20KB-60KB. =)

-- wli
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.129 / U:9.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site