[LU-30] improve & cleanup ldlm_handle_enqueue Created: 22/Dec/10  Updated: 13/Feb/19

Status: In Progress
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.0.0
Fix Version/s: Lustre 2.1.0

Type: Improvement Priority: Minor
Reporter: Liang Zhen (Inactive) Assignee: WC Triage
Resolution: Unresolved Votes: 0
Labels: None

Rank (Obsolete): 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.


 Comments   
Comment by Liang Zhen (Inactive) [ 22/Dec/10 ]

Oleg, I pulled you in as watcher in case you have any suggestion or concern on this, thanks

Comment by Liang Zhen (Inactive) [ 25/Dec/10 ]

Oleg, I've uploaded the first version of patch to http://review.whamcloud.com/#change,153 , but I can't find you gerrit account, could you please review it because I need your expertise of ldlm

Thanks
Liang

Generated at Sat Feb 10 01:03:03 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.