lkml.org 
[lkml]   [2017]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[PATCH 0/5] inofify: Reduce lock contention on read()
Date
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

\
 
 \ /
  Last update: 2017-03-24 22:38    [W:1.395 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site