쓰기 프로세스로 인해 발생하는 잠금 경합을 측정해 달라는 요청을 받았습니다. 해당 쓰기 프로세스에 대한 잠금 상태 데이터를 보고 있습니다.
내 질문은 다음과 같습니다.
경합은 스레드가 특정 잠금을 기다리는 횟수(다른 스레드가 해당 잠금을 보유하고 있기 때문에) 또는 해당 잠금이 해제될 때까지 스레드가 기다려야 하는 시간과 관련되어 있습니까?
경합을 두 가지 모두의 척도로 계산하는 것이 올바른가요?
- 나노초(스레드가 이벤트 발생/잠금 해제를 기다려야 하는 평균 시간) 및
- cnt(이벤트가 발생한 횟수)
특정 잠금에 대해 lockstat에서 수집된 데이터를 프로파일링합니까? 즉 경합 ~ nsec * cnt
답변1
Linux 커널 문서를 보면 잠금이 해제되기를 기다리는 것처럼 보입니다.
- HOW
Lockdep already has hooks in the lock functions and maps lock instances to
lock classes. We build on that (see Documentation/locking/lockdep-design.txt).
The graph below shows the relation between the lock functions and the various
hooks therein.
__acquire
|
lock _____
| \
| __contended
| |
| <wait>
| _______/
|/
|
__acquired
|
.
<hold>
.
|
__release
|
unlock
lock, unlock - the regular lock functions
__* - the hooks
<> - states
노트:해당 링크를 살펴보면 사용법도 나와 있습니다.
경쟁 측정
mutrace
그런데, 주어진 실행 파일에 대한 경합을 계산하는 데 사용할 수도 있습니다 . 이에 대해서는 다음 제목의 기사에서 설명합니다.잠금 경합 측정.
예를 들어
$ LD_PRELOAD=/home/lennart/projects/mutrace/libmutrace.so gedit
mutrace: 0.1 sucessfully initialized.
mutrace: 10 most contended mutexes:
Mutex # Locked Changed Cont. tot.Time[ms] avg.Time[ms] max.Time[ms] Type
35 368268 407 275 120,822 0,000 0,894 normal
5 234645 100 21 86,855 0,000 0,494 normal
26 177324 47 4 98,610 0,001 0,150 normal
19 55758 53 2 23,931 0,000 0,092 normal
53 106 73 1 0,769 0,007 0,160 normal
25 15156 70 1 6,633 0,000 0,019 normal
4 973 10 1 4,376 0,004 0,174 normal
75 68 62 0 0,038 0,001 0,004 normal
9 1663 52 0 1,068 0,001 0,412 normal
3 136553 41 0 61,408 0,000 0,281 normal
... ... ... ... ... ... ... ...
mutrace: Total runtime 9678,142 ms.