Please don't reply to lustre-devel. Instead, comment in Bugzilla by using the
following link:
https://bugzilla.lustre.org/show_bug.cgi?id=10902
What |Removed |Added
----------------------------------------------------------------------------
Attachment #9248 is|0 |1
obsolete| |
Created an attachment (id=9273)
Please don't reply to lustre-devel. Instead, comment in Bugzilla by using the
following link:
--> (https://bugzilla.lustre.org/attachment.cgi?id=9273&action=view)
code for PLAIN/IBITS granted list improvement (revision 4)
> 1. Oleg, your optimization above does not look very helpful.
> Once a lock with a compatible mode occurs, we skip all the
> locks of this mode by mode skip list -- locks are grouped by
> mode. As we do not walk through locks with compatible modes,
> your optimization works for the very first lock in every compatible
> mode group only. I do not think we need an optimization that
> works for 1 lock per mode group of locks.
well, i didn't change it in this patch, need Oleg's feedback of your opinion.
> 2. we should probably check in search_grant_lock() if @lock is
> not plain nor inodebits type, and LBUG if so.
included in this patch.
> 3. when we call ldlm_granted_list_add_lock(), we do not call
> ldlm_resource_add_lock() anymore. Thus ldlm_granted_list_add_lock()
> should print the same debug info as ldlm_resource_add_lock() does.
> It also should handle destroyed locks in the same way.
included in this patch.
> 4. ldlm_lock_convert()
> if the lock is in the middle of the mode and policy groups,
> @mark_lock will be NULL and the lock will be inserted later
> to the end of the granted list in ldlm_granted_list_add_lock(),
> what is wrong.
when lock is in the middle of the mode/policy group, code in lines(1552-1554)
of
ldlm_lock.c will be hit
1548 if ((join & LDLM_MODE_JOIN_LEFT) ||
1549 (join & LDLM_POLICY_JOIN_LEFT))
1550 mark_lock = list_entry(lock->l_res_link.prev,
1551 struct ldlm_lock,
l_res_link);
1552 else if (lock->l_res_link.next != &res->lr_granted)
1553 mark_lock = list_entry(lock->l_res_link.next,
1554 struct ldlm_lock,
l_res_link);
so the mark_lock will not be NULL in this case.
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel
