Skip to content
  • Patrick Farrell's avatar
    LU-6179 llite: Implement ladvise lockahead · a8dcf372
    Patrick Farrell authored
    
    
    Ladvise lockahead is a new feature allowing userspace to
    request extent locks in advance of the IO which will use
    them. These locks are not expanded beyond the size
    requested by userspace.  They are intended to make it
    possible to address lock contention between multiple
    clients resulting from lock expansion.  They should allow
    optimizing various IO patterns, notably strided writing.
    (Further information in LU-6179)
    
    Asynchronous glimpse locks are a speculative version of
    glimpse locks, and already implement the required behavior.
    Lockahead requests share this behavior.
    
    Additionally, lockahead creates extent locks in advance
    of IO, and so breaks the assumption that the holder of the
    highest lock knows the current file size.
    
    So we also modify the ofd_intent_policy code to glimpse
    PW locks until it finds one it knows to be in use, taking
    care to send only one glimpse to each client.
    
    The current patch allows asynchronous non-blocking lock
    ahead requests and synchronous blocking requests.  We
    cannot do asynchronous blocking requests, because of
    deadlocks that occur in having ptlrpcd threads handle
    blocking lock requests.
    
    Finally, this patch also adds another advice to disable
    lock expansion, setting a per-file descriptor flag.  This
    allows user space to control whether or not lock requests
    on this file descriptor will undergo lock expansion.
    
    This means if lockahead locks are not created ahead of IO
    (due to inherent raciness) or are cancelled by a competing
    IO request, the IO requests that should have used the
    manually requested locks will not result in expanded locks.
    This avoids lock ping-pong, and because the resulting locks
    will not extend to the end of the file, future lockahead
    requests can be granted.  Effectively, this means that if
    lockahead usage for strided IO is interrupted by a
    competing request, it can re-assert itself.
    
    lockahead is implented via the ladvise interface from
    userspace.  As lockahead results in a DLM lock request
    rather than file advice, we do not use the lower levels of
    the ladvise implementation.
    
    Note this patch has one oddity:
    Cray released an earlier version of lockahead without
    FL_SPECULATIVE support.  That version uses
    OBD_CONNECT_LOCKAHEAD_OLD, this new one uses
    OBD_CONNECT_LOCKAHEAD.
    
    The client code in this patch is interoperable with that
    version, so it also advertises OBD_CONNECT_LOCKAHEAD_OLD
    support, but the server version is not, so the server
    advertises only OBD_CONNECT_LOCKAHEAD support.
    
    Client support for the original lockahead is slated for
    removal after the release of 2.12.  This is enforced with
    a compile time version test that will remove support.
    
    Signed-off-by: default avatarPatrick Farrell <paf@cray.com>
    Change-Id: I1e80286f54946a0df08b19b1339829fcfd1117e7
    Reviewed-on: https://review.whamcloud.com/13564
    
    
    Tested-by: Jenkins
    Reviewed-by: default avatarAndreas Dilger <andreas.dilger@intel.com>
    Reviewed-by: default avatarJinshan Xiong <jinshan.xiong@intel.com>
    Tested-by: default avatarMaloo <hpdd-maloo@intel.com>
    Reviewed-by: default avatarFrank Zago <fzago@cray.com>
    Reviewed-by: default avatarOleg Drokin <oleg.drokin@intel.com>
    a8dcf372