diff options
author | Jeff Layton <jlayton@redhat.com> | 2008-12-05 20:41:21 -0500 |
---|---|---|
committer | Steve French <sfrench@us.ibm.com> | 2008-12-26 02:29:11 +0000 |
commit | 85705524258f93a6086c3247a58f34a661b82b3d (patch) | |
tree | 8cd8f39a92f649e5bce8001331e9b5a8a4c9e650 /fs/internal.h | |
parent | 8be0ed44c2fa4afcf2c6d2fb3102c926e9f989df (diff) | |
download | linux-85705524258f93a6086c3247a58f34a661b82b3d.tar.bz2 |
cifs: fix wait_for_response to time out sleeping processes correctly
cifs: fix wait_for_response to time out sleeping processes correctly
The current scheme that CIFS uses to sleep and wait for a response is
not quite what we want. After sending a request, wait_for_response puts
the task to sleep with wait_event(). One of the conditions for
wait_event is a timeout (using time_after()).
The problem with this is that there is no guarantee that the process
will ever be woken back up. If the server stops sending data, then
cifs_demultiplex_thread will leave its response queue sleeping.
I think the only thing that saves us here is the fact that
cifs_dnotify_thread periodically (every 15s) wakes up sleeping processes
on all response_q's that have calls in flight. This makes for
unnecessary wakeups of some processes. It also means large variability
in the timeouts since they're all woken up at once.
Instead of this, put the tasks to sleep with wait_event_timeout. This
makes them wake up on their own if they time out. With this change,
cifs_dnotify_thread should no longer be needed.
I've been testing this in conjunction with some other patches that I'm
working on. It doesn't seem to affect performance at all with with heavy
I/O. Identical iozone -ac runs complete in almost exactly the same time
(<1% difference in times).
Thanks to Wasrshi Nimara for initially pointing this out. Wasrshi, it
would be nice to know whether this patch also helps your testcase.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Cc: Wasrshi Nimara <warshinimara@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Diffstat (limited to 'fs/internal.h')
0 files changed, 0 insertions, 0 deletions