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@xxxxxxxxx> 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 > _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
