diff options
author | Waiman Long <Waiman.Long@hp.com> | 2013-09-12 10:55:34 -0400 |
---|---|---|
committer | Chanho Park <chanho61.park@samsung.com> | 2014-11-21 19:12:26 +0900 |
commit | 384b43ecf124f8f0959e92252b0a0c1b4996fe0c (patch) | |
tree | ae1ce4d3bac0c4dc138289e170d462dc0b5e5ec4 /net/dcb | |
parent | 05b299ac988974286d878ad6ca0a02e5fc9af3b6 (diff) | |
download | linux-3.10-384b43ecf124f8f0959e92252b0a0c1b4996fe0c.tar.gz linux-3.10-384b43ecf124f8f0959e92252b0a0c1b4996fe0c.tar.bz2 linux-3.10-384b43ecf124f8f0959e92252b0a0c1b4996fe0c.zip |
seqlock: Add a new locking reader type
The sequence lock (seqlock) was originally designed for the cases where
the readers do not need to block the writers by making the readers retry
the read operation when the data change.
Since then, the use cases have been expanded to include situations where
a thread does not need to change the data (effectively a reader) at all
but have to take the writer lock because it can't tolerate changes to
the protected structure. Some examples are the d_path() function and
the getcwd() syscall in fs/dcache.c where the functions take the writer
lock on rename_lock even though they don't need to change anything in
the protected data structure at all. This is inefficient as a reader is
now blocking other sequence number reading readers from moving forward
by pretending to be a writer.
This patch tries to eliminate this inefficiency by introducing a new
type of locking reader to the seqlock locking mechanism. This new
locking reader will try to take an exclusive lock preventing other
writers and locking readers from going forward. However, it won't
affect the progress of the other sequence number reading readers as the
sequence number won't be changed.
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'net/dcb')
0 files changed, 0 insertions, 0 deletions