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

improve & cleanup ldlm_handle_enqueue

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Minor
    • Lustre 2.1.0
    • Lustre 2.0.0
    • None
    • 10502

    Description

      current ldlm_handle_enqueue0 is a huge function, it's so big and too complex to read, I would like to cleanup it for some reasons:

      • just cleanup code and make it easier to understand
      • for MDT stack (non-replay request), the lock created in ldlm_handle_enqueue0 is not really necessary, mdt_intent_policy() will always create it's own lock and replace it (if we need to return a lock), we probably can't just ignore overhead of the redundant lock although it's never granted, especially for the case of many clients are accessing a shared directory at the same time.
        • overhead of add/remove items to/from namespace::ns_rs_hash
        • overhead of add/remove items to/from lustre-handle hash
        • overhead of add/remove items to/from exp_lock_hash
        • destroying lock need to content on ldlm_resource:lr_lock
        • overhead of all kinds of counters
        • overhead of memory allocate/free
      • some small bugs, i.e: bug 24324, which has been fixed, but I think there are some other small issues.

      Attachments

        Activity

          People

            wc-triage WC Triage
            liang Liang Zhen (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: