[#LU-82] CLIO lock cache caching useless locks

[LU-82] CLIO lock cache caching useless locks Created: 09/Feb/11 Updated: 27/Nov/12 Resolved: 27/Nov/12
Status:	Resolved
Project:	Lustre
Component/s:	None
Affects Version/s:	Lustre 2.0.0, Lustre 2.1.0
Fix Version/s:	Lustre 2.1.0

Type:

Bug

Priority:

Critical

Reporter:

Oleg Drokin

Assignee:

Jinshan Xiong (Inactive)

Resolution:

Fixed

Votes:

Labels:

None

Severity:

Rank (Obsolete):

4015

Description

It seems that top locks cache is not killing locks that don't have any valid sublocks left, so this cache for actively used files grows to tens of locks easily slowing everything down.
To make things worse, sometimes these useless locks are matched against really wanted locks, but the cached lock is wider, so we try to enqueue a lock much wider than we actually need which leads to even more of a slowdown with shared file access.

Comments

Comment by Jinshan Xiong (Inactive) [ 09/Feb/11 ]

patch is at: http://review.whamcloud.com/227

Comment by Oleg Drokin [ 09/Feb/11 ]

Reassign to Jay since he is working on it.

Comment by Jinshan Xiong (Inactive) [ 18/Feb/11 ]

Let me describe this problem a little bit in detail so as to help inspect.

The root cause of this problem is due to the handling inside cl_lock_request(), where:

rc = cl_enqueue_locked(env, lock, io, enqflags);
if (rc == 0) {
if (cl_lock_fits_into(env, lock, need, io))

{ cl_lock_mutex_put(env, lock); cl_lock_lockdep_acquire(env, lock, enqflags); break; }

cl_unuse_locked(env, lock);

If a lock was matched but it turns out to not fit after queuing(this may happen if there is a race that the sublock was canceled, and then a new sublock is created), cl_unuse_locked will put the lock into CLS_NEW state. Some time later, when the sublock of this lock is canceled, it won't delete the top lock because its state is CLS_NEW. The new patch just does it.

Comment by Build Master (Inactive) [ 07/Mar/11 ]

Integrated in reviews-centos5 #407
~~LU-82~~ Remove useless clio locks