understand the result of lockstat

Zheng Da zhengda1936 at gmail.com
Thu Oct 6 12:04:50 EDT 2011


Sorry, I made a mistake. The result I showed before wasn't read with 8 threads.

Here they are:
&(&zone->lock)->rlock	4787	4787	0	0	20215.41	78501	155282	0	0	624183.01
&rq->lock	18901	18922	0	0	40136.01	45026	406767	0	0	512871.34
&(&zone->lru_lock)->rlock	18141	18244	0	27.17	54954.92	213472	510454	0	9.75	1052236.92
&(&(ei->i_block_reservation_lock))->r	114490	115557	-0.24	122.45	94593.08	889026	1700797	-0.21	0	757448.12
&anon_vma->mutex	797	887	-0.3	2270.25	207611.22	1419	36308	0	0	51666.33
&mapping->i_mmap_mutex	1545	1545	-0.38	8448.55	497624.63	3066	41662	0	0	58813.61
&(&mapping->tree_lock)->rlock	1045835	1097042	0	0	1834205.73	2095053	4480816	0	0	2329903.66
&(&dentry->d_lock)->rlock	1627856	1714213	-0.02	105.42	5828953.37	2632934	4678428	0	4553.68	1442449.52
Even so, the most contended lock waits for about 6ms in total, and the
entire read takes 11seconds, which it seems to me isn't much if the
unit of waittime is nanosecond.

Thanks,
Da

On Thu, Oct 6, 2011 at 11:25 AM, Zheng Da <zhengda1936 at gmail.com> wrote:
> Hello,
>
> I try to analyze the lock contention in the linux FS, so I enable
> lockstats in the kernel. But I have some troubles to understand the
> result in lockstats.
> When I read 4GB data randomly from a file on a ramdisk with 8 threads
> (I have 8 cores), and it takes 21 seconds.
> The most contended lock is
> class name                              con-bounces     contentions     waittime-min    waittime-max
>        waittime-total  acq-bounces     acquisitions    holdtime-min    holdtime-max    holdtime-total
> &(&mapping->tree_lock)->rlock   104380          104615          0                       0                       61705.23                169228          2862470         0                       0                       1010557.22
> &(&zone->lru_lock)->rlock               1233                    1245                    0                       0                       2632.71         21834           255752          0                       3.86                    402904.1
> xtime_lock                                      722                     731                     0                       0                       1916.15         1342                    2901                    0                       0                       4812.51
> What is unit of the waittime? in nanoseconds? I look into the code of
> x86, and it seems the clock time the code reads is nanoseconds. But if
> it's in nanoseconds, the wait time of mapping->tree_lock is very
> short, only 62us in total?
> Also, the result shows that there are 104615 contentions out of
> 2862470 acquisitions. I guess it's not very highly contended.
>
> Thanks,
> Da
>



More information about the Kernelnewbies mailing list