From: Bill H. <ha...@au...> - 2001-09-28 22:33:59
|
John Hawkes wrote: > > All (29) CPUs > > Start time: Fri Sep 14 07:03:06 2001 > End time: Fri Sep 14 07:26:13 2001 > Delta Time: 1386.79 sec. > Hash table slots in use: 408. > Global read lock slots in use: 999. > > > 34.6% 42.0% 37us( 15ms) 510us(2153ms)( 6.8%) 12836038 58.0% 42.0% 0% kernel_flag > 6.9% 41.3% 33us(8077us) 513us(2153ms)( 1.5%) 2896012 58.7% 41.3% 0% ext2_get_block+0xd0 > 17.0% 64.7% 289us( 12ms) 659us(1018ms)(0.86%) 815966 35.3% 64.7% 0% ext2_write_inode+0x50 > 1.1% 47.9% 20us(5817us) 514us( 830ms)(0.46%) 749250 52.1% 47.9% 0% notify_change+0xd0 > 1.3% 64.9% 22us(6858us) 649us(1961ms)(0.88%) 842833 35.1% 64.9% 0% schedule+0xd60 > 1.9% 34.5% 4.9us(3042us) 435us(2081ms)( 2.0%) 5448856 65.5% 34.5% 0% sys_lseek+0x100 > > ==> kernel_flag is the dominant bottleneck for this workload on this > ==> platform. Kernprof profiling shows the top three CPU consumers > ==> are sys_lseek(), ext2_get_block(), and the idle loop. > I thought there was some discussion a while back about sys_lseek and the kernel lock. I have not followed the code path. Does anyone know why the kernel lock is required in this code path ? Bill |