• Alexander Aring's avatar
    fs: dlm: parallelize lowcomms socket handling · dbb751ff
    Alexander Aring authored
    This patch is rework of lowcomms handling, the main goal was here to
    handle recvmsg() and sendpage() to run parallel. Parallel in two senses:
    1. per connection and 2. that recvmsg()/sendpage() doesn't block each
    other.
    
    Currently recvmsg()/sendpage() cannot run parallel because two
    workqueues "dlm_recv" and "dlm_send" are ordered workqueues. That means
    only one work item can be executed. The amount of queue items will be
    increased about the amount of nodes being inside the cluster. The current
    two workqueues for sending and receiving can also block each other if the
    same connection is executed at the same time in dlm_recv and dlm_send
    workqueue because a per connection mutex for the socket handling.
    
    To make it more parallel we introduce one "dlm_io" workqueue which is
    not an ordered workqueue, the amount of workers are not limited. Due
    per connection flags SEND/RECV pending we schedule workers ordered per
    connection and per send and receive task. To get rid of the mutex
    blocking same workers to do socket handling we switched to a semaphore
    which handles socket operations as read lock and sock releases as write
    operations, to prevent sock_release() being called while the socket is
    being used.
    
    There might be more optimization removing the semaphore and replacing it
    with other synchronization mechanism, however due other circumstances
    e.g. othercon behaviour it seems complicated to doing this change. I
    added comments to remove the othercon handling and moving to a different
    synchronization mechanism as this is done. We need to do that to the next
    dlm major version upgrade because it is not backwards compatible with the
    current connect mechanism.
    
    The processing of dlm messages need to be still handled by a ordered
    workqueue. An dlm_process ordered workqueue was introduced which gets
    filled by the receive worker. This is probably the next bottleneck of
    DLM but the application can't currently parse dlm messages parallel. A
    comment was introduced to lift the workqueue context of dlm processing
    in a non-sleepable softirq to get messages processing done fast.
    Signed-off-by: default avatarAlexander Aring <aahringo@redhat.com>
    Signed-off-by: default avatarDavid Teigland <teigland@redhat.com>
    dbb751ff
lowcomms.c 47.2 KB