Hi,
Running inotify on a very large number hierachy of directories and
files can result in major lock contention between the producer and
consumer of events.
The current code takes the spinlock when pulling each event off the
queue, which isn't overly idea. This patchset reduces the lock
contention by splicing off the event queue while processing reads and
putting the leftover events back on the queue once the read buffer is
full. In order to ensure ordering when reading events, a mutex is
added to read().
While this should reduce the number of locks taken on read when
reading in bulk, it does increase the overhead for the case where the
users tries to read one event at a time.
Last, the first patch of the series adds the missing mutex_destoy()
for mark_mutex.
Thoughts?
Jes
Jes Sorensen (5):
notify: Call mutex_destroy() before freeing mutex memory
inotify: Use mutex to prevent threaded clients reading events out of
order
notify: Split up some fsnotify functions
inotify: switch get_one_event() to use fsnotify_list_*() helpers
inotify: Avoid taking spinlock for each event processed in read()
fs/notify/group.c | 1 +
fs/notify/inotify/inotify_fsnotify.c | 1 +
fs/notify/inotify/inotify_user.c | 42 ++++++++++++++++++++++++++++--------
fs/notify/notification.c | 38 ++++++++++++++++++++++++++------
include/linux/fsnotify_backend.h | 7 ++++++
5 files changed, 73 insertions(+), 16 deletions(-)
--
2.9.3
