summaryrefslogtreecommitdiffstats
path: root/include/video/mbxfb.h
diff options
context:
space:
mode:
authorWaiman Long <Waiman.Long@hp.com>2013-09-12 10:55:34 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2013-09-12 09:25:23 -0700
commit1370e97bb2eb1ef2df7355204e5a4ba13e12b861 (patch)
tree9e3c2e9b0e0a7f67e50898e8ff5ecb462f260625 /include/video/mbxfb.h
parentdecf7abcc97444ecd2d3cf278f5cc8093f33f49a (diff)
downloadtalos-op-linux-1370e97bb2eb1ef2df7355204e5a4ba13e12b861.tar.gz
talos-op-linux-1370e97bb2eb1ef2df7355204e5a4ba13e12b861.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 'include/video/mbxfb.h')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud