Bart Smaalders wrote On 11/08/06 07:47,:
...
A quick check with libmicro indicates Prakash's suggestion scales
very nicely indeed, and will not change semantics at all. Just have
each thread dup(2) its crypto fd and all the contention in getf will
disappear.
Yes. We also noticed the same re
prakash sangappa wrote:
The 'uf_lock' is a per 'fd' lock. Therefore, the application could
possibly dup(2)
the fd, to get one for each thread. That should help avoid the uf_lock
contention.
-Prakash.
Krishna Yenduri wrote:
Bart Smaalders wrote:
Krishna Yenduri wrote:
...
This lock is u
The 'uf_lock' is a per 'fd' lock. Therefore, the application could
possibly dup(2)
the fd, to get one for each thread. That should help avoid the uf_lock
contention.
-Prakash.
Krishna Yenduri wrote:
Bart Smaalders wrote:
Krishna Yenduri wrote:
...
This lock is uf_lock of the device file
Bart Smaalders wrote:
Krishna Yenduri wrote:
...
This lock is uf_lock of the device file descriptor on which the ioctl
is being done. This contention is surprising to me because the
routine getf()
seems to be optimized for scaling.
Any ideas on what kind of solution is possible here? We ar
Krishna Yenduri wrote:
Hi All,
Our team is doing some micro benchmarks on a multi CPU machine
and found the following hot locks from lockstat(1M) when using 32 threads.
The benchmark does an ioctl() on /dev/crypto in a while loop.
Adaptive mutex spin: 7123153 events in 30.966 seconds (230029 ev
Hi All,
Our team is doing some micro benchmarks on a multi CPU machine
and found the following hot locks from lockstat(1M) when using 32 threads.
The benchmark does an ioctl() on /dev/crypto in a while loop.
Adaptive mutex spin: 7123153 events in 30.966 seconds (230029 events/sec)
Count indv cu
