1. 12 Nov, 2010 1 commit
    • Steven Whitehouse's avatar
      dlm: Use cmwq for send and receive workqueues · dcce240e
      Steven Whitehouse authored
      So far as I can tell, there is no reason to use a single-threaded
      send workqueue for dlm, since it may need to send to several sockets
      concurrently. Both workqueues are set to WQ_MEM_RECLAIM to avoid
      any possible deadlocks, WQ_HIGHPRI since locking traffic is highly
      latency sensitive (and to avoid a priority inversion wrt GFS2's
      glock_workqueue) and WQ_FREEZABLE just in case someone needs to do
      that (even though with current cluster infrastructure, it doesn't
      make sense as the node will most likely land up ejected from the
      cluster) in the future.
      Signed-off-by: default avatarSteven Whitehouse <swhiteho@redhat.com>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      dcce240e
  2. 11 Nov, 2010 1 commit
    • David Miller's avatar
      dlm: Handle application limited situations properly. · b36930dd
      David Miller authored
      In the normal regime where an application uses non-blocking I/O
      writes on a socket, they will handle -EAGAIN and use poll() to
      wait for send space.
      
      They don't actually sleep on the socket I/O write.
      
      But kernel level RPC layers that do socket I/O operations directly
      and key off of -EAGAIN on the write() to "try again later" don't
      use poll(), they instead have their own sleeping mechanism and
      rely upon ->sk_write_space() to trigger the wakeup.
      
      So they do effectively sleep on the write(), but this mechanism
      alone does not let the socket layers know what's going on.
      
      Therefore they must emulate what would have happened, otherwise
      TCP cannot possibly see that the connection is application window
      size limited.
      
      Handle this, therefore, like SUNRPC by setting SOCK_NOSPACE and
      bumping the ->sk_write_count as needed when we hit the send buffer
      limits.
      
      This should make TCP send buffer size auto-tuning and the
      ->sk_write_space() callback invocations actually happen.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
      b36930dd
  3. 09 Nov, 2010 5 commits
  4. 08 Nov, 2010 17 commits
  5. 06 Nov, 2010 7 commits
  6. 05 Nov, 2010 9 commits