In article <[EMAIL PROTECTED]>,
Rudy Moore <[EMAIL PROTECTED]> wrote:
>
>The problem with that approach is that it won't give you an accurate
>result. By changing the size and instructions in the spinlock code
>you're changing how it behaves... So you'll get profiling data on
>something that you're not really interested in.
>
>Another idea - still not perfect - would be to check system time before
>you enter the lock and after you exit.
Note that the easiest way to do spinlock profiling is actually to just
do a normal "profile" of the kernel, and looking into the ".text_lock"
part of the profile. That works for spinlocks that don't disable
interrupts, notably the kernel lock (which is the biggest one by far).
There are various kernel profiling programs out there that just read
/proc/profile and parse the output. That's what I do, and it's very
instructive (you can tell not only which spinlock, but _what_invocation_
of the lock that is the one that gets the worst behaviour).
For example, doing the above for compiling a kernel in parallell on a
4-way CPU shows very clearly that the worst case is the kernel lock, and
in particular the two places that get a lot of lock contention on that
are the ones in sys_brk() (mm/mmap.c) and in handle_pte_fault()
(mm/memory.c).
(That's silly, as sys_brk() in theory doesn't need the kernel lock at
all, but the way it is implemented right now we have to acquire it -
this is one of the things I'll be fixing in 2.3.x)
Linus
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
