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@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