lkml.org 
[lkml]   [2012]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: semaphore and mutex in current Linux kernel (3.2.2)

* Chen, Dennis (SRDC SW) <Dennis1.Chen@amd.com> wrote:

> > Well, a way to reproduce that would be to find a lock_mutex
> > intense workload ('perf top -g', etc.), and then changing back
> > the underlying mutex to a semaphore, and measure the performance
> > of the two primitives.
>
> Why not the 'test-mutex' tool in the document?
>
> I guess it should be the private tool from you, if you can
> share it to me then I can help to make a new round performance
> check of the two primitives in the latest kernel... make a
> deal?

I think I posted it back then - but IIRC it was really just
open-coded mutex fastpath executed in user-space by a couple of
threads. To do that today you'd have to create it anew: just
copy the current mutex fast-path to user-space and measure it.

I'm not sure what the point of comparative measurements with
semaphores would be: for example we don't have per architecture
optimized semaphores anymore, we switched the legacy semaphores
to a generic version and are phasing them out.

Mutexes have various advantages (such as lockdep coverage and in
general tighter semantics that makes their usage more robust)
and we aren't going back to semaphores.

What would make a ton of sense would be to create a 'perf bench'
module that would use the kernel's mutex code and would measure
it in user-space. 'perf bench mem' already does a simplified
form of that: it measures the kernel's memcpy and memset
routines:

$ perf bench mem memcpy -r help
# Running mem/memcpy benchmark...
Unknown routine:help
Available routines...
default ... Default memcpy() provided by glibc
x86-64-unrolled ... unrolled memcpy() in arch/x86/lib/memcpy_64.S
x86-64-movsq ... movsq-based memcpy() in arch/x86/lib/memcpy_64.S
x86-64-movsb ... movsb-based memcpy() in arch/x86/lib/memcpy_64.S

$ perf bench mem memcpy -r x86-64-movsq
# Running mem/memcpy benchmark...
# Copying 1MB Bytes ...

2.229595 GB/Sec
10.850694 GB/Sec (with prefault)

$ perf bench mem memcpy -r x86-64-movsb
# Running mem/memcpy benchmark...
# Copying 1MB Bytes ...

2.055921 GB/Sec
2.447525 GB/Sec (with prefault)

So what could be done is to add something like:

perf bench locking mutex

Which would, similarly to tools/perf/bench/mem-memcpy-x86-64-asm.S
et al inline the mutex routines, would build user-space glue
around them and would allow them to be measured.

Such a new feature could then be used to improve mutex
performance in the future. Likewise:

perf bench locking spinlock

could be used to do something similar to spinlocks - measuring
them contended and uncontended, cache-cold and cache-hot, etc.

This would then be used by all future kernel developer
generations to improve these locking primitives - avoiding the
test-mutex kind of obscolescence and bitrot :-)

So if you'd be interested in writing that brand new benchmarking
feature and need help then let the perf people know.

Thanks,

Ingo


\
 
 \ /
  Last update: 2012-04-03 09:55    [W:0.053 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site