aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts.py
diff options
context:
space:
mode:
authorPatrick Farrell <[email protected]>2016-10-02 22:28:12 -0400
committerGreg Kroah-Hartman <[email protected]>2016-10-16 10:24:29 +0200
commit594efc4244b0ccd73d0bebf86db3261c3a951f9d (patch)
treee9bc515e8dcc284ae1e6f072c6e50a8488d36bb5 /tools/perf/scripts/python/syscall-counts.py
parentdb431dad75198b03ba47769b920843b4557c02cd (diff)
staging: lustre: ldlm: Do not use cbpending for group locks
Currently, the CBPENDING flag is set on group locks when the osc lock above them is released (osc_cancel_base). This results in a situation where a new group lock request on a resource does not match an existing group lock because LDLM_FL_CBPENDING is set on the existing lock. So two group locks are granted on the same resource, which is not valid, since a given client can only have one group lock on a particular resource. Since group locks are manually released and not called back like other LDLM locks, the CBPENDING flag doesn't make sense. Since they must be manually released, they also cannot go in the LDLM LRU cache and must be fully released immediately once they are no longer in use. This was previously accomplished by setting CBPENDING when the corresponding osc lock is released, but as noted above, this prevents the group lock matching some future lock requests. This patch uses the fact that group locks have an l_writers reference which they keep until they are manually released, so we remove them when they have no more reader or writer references, without checking cbpending. Signed-off-by: Patrick Farrell <[email protected]> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-6368 Reviewed-on: http://review.whamcloud.com/14093 Reviewed-by: frank zago <[email protected]> Reviewed-by: Jinshan Xiong <[email protected]> Reviewed-by: Oleg Drokin <[email protected]> Signed-off-by: James Simmons <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts.py')
0 files changed, 0 insertions, 0 deletions