Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-4801

spin lock contention in lock_res_and_lock

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Major
    • None
    • Lustre 2.4.1
    • lustre-2.4.0-26chaos
    • 3
    • 13209

    Description

      Our MDS experienced severe lock contention in lock_res_and_lock(). This had a large impact on client responsiveness because service threads were starved for CPU time. We have not yet identified the client workload that caused this problem. All active tasks had stack traces like this, but would eventually get scheduled out.

       ...
__spin_lock
lock_res_and_lock
ldlm_handle_enqueue0
mdt_handle_common
mds_regular_handle
ptlrpc_server_handle_request
...

      This raises the question of why the ldlm resource lock needs to be a spinlock. Couldn't we avoid this issue by converting it to a mutex? This question was raised in LU-3504.

      Attachments

        1. parallel_flock_v2.c
          3 kB
          Oleg Drokin
        2. parallel_flock.c
          3 kB
          Oleg Drokin

        Issue Links

          is related to

          Improvement - An improvement or enhancement to an existing feature or task. LU-12542 LDLM improvements form linux lustre client work

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-3504 MDS: All cores spinning on ldlm lock in lock_res_and_lock

          • Major - Major loss of function.
          • Resolved

          Activity

            People

              green Oleg Drokin
              nedbass Ned Bass (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: