There are several key variables that determine how long a lock request
- does the lock request require a resource directory lookup
- is the directory node for a resource local or remote
- is the master node for a resource local or remote
- if a remote directory lookup is necessary, is the remote node also the
master of the resource
- is the request for a new lock or a conversion of an existing lock
- if the request is a conversion, is it a promotion or a demotion
At best, a lock request will require zero remote operations, and at worst
it will require two. More nodes increase the chance of the directory node
being remote, but do not effect the time of a lock request otherwise. The
time really depends on whether there are 0, 1 or 2 remote operations
(network requests) required.
Some rough figures from a P3 700MHz machine. The requests are made from
the kernel using the standard dlm locking api.
320 ms to acquire 10000 new locks, all local resource dir lookups, all
locally mastered, no remote operations
62 ms to convert 10000 existing locks, all locally mastered, no remote
2500 ms to up-convert 10000 existing locks, all remotely mastered
580 ms to down-convert 10000 existing locks, all remotely mastered
3800 ms to acquire 10000 new locks, all remotely mastered, 3 nodes in the
lockspace. Two thirds of the locks required remote directory lookups, all
10000 required remote lock requests, one third involved a combined lookup
and lock request. That's a total of about 13000 network requests.
There is more measurement to be done, but at this point the results become
rather involved because of the mix of remote and local operations.