diff options
author | Steven Whitehouse <swhiteho@redhat.com> | 2006-09-11 21:40:30 -0400 |
---|---|---|
committer | Steven Whitehouse <swhiteho@redhat.com> | 2006-09-11 21:40:30 -0400 |
commit | 24264434603cc102d71fb2a1b3b7e282a781f449 (patch) | |
tree | 18af5274fa222f0420df30651f57bab1eaf75eab /kernel | |
parent | 94610610f10749c0e17b4d2840ff8a7cb636c413 (diff) | |
download | linux-24264434603cc102d71fb2a1b3b7e282a781f449.tar.gz linux-24264434603cc102d71fb2a1b3b7e282a781f449.tar.bz2 linux-24264434603cc102d71fb2a1b3b7e282a781f449.zip |
[GFS2] Rewrite of examine_bucket()
The existing implementation of this function in glock.c was not
very efficient as it relied upon keeping a cursor element upon the
hash chain in question and moving it along. This new version improves
upon this by using the current element as a cursor. This is possible
since we only look at the "next" element in the list after we've
taken the read_lock() subsequent to calling the examiner function.
Obviously we have to eventually drop the ref count that we are then
left with and we cannot do that while holding the read_lock, so we
do that next time we drop the lock. That means either just before
we examine another glock, or when the loop has terminated.
The new implementation has several advantages: it uses only a
read_lock() rather than a write_lock(), so it can run simnultaneously
with other code, it doesn't need a "plug" element, so that it removes
a test not only from this list iterator, but from all the other glock
list iterators too. So it makes things faster and smaller.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions