Andi Kleen writes:
> kumon@flab.fujitsu.co.jp writes:
> > Schedule(), sock_poll(), do_close(), do_select() are those sacrificed
> > functions. When the number of CPUs is increased, or some of CPUs are
> > slower than the others, this exclusion severely damaged performance
> > increase.
>
> schedule() does not require the kernel lock
Unfortunately, schedule() does.
Of cource whole function is not protected by the lock.
But, the measurement shows most spin-lock overhead caused by the
kernel lock is occured in schedule().
# The measurement is based on rather old 2.3.40, for histrical reason.
The following kernel lock acquirement is the most time consuming spin-lock
portion. The code is near line 600 in sched.c. the location is almost same
in 2.3.40 or 2.3.99-pre5.
>> same_process:
>> reacquire_kernel_lock(current);
The following is the precise analysis of slock-text section time consumer.
The number has only relative meaning.
;cpu0 cpu1 cpu2 cpu3 all-cpu from where lockvar
1279 1304 1258 1155 4996 TOTAL
346 360 387 390 1483 schedule+2000 0xc02689c4
160 165 148 126 599 sock_poll+232 0xc02689c4
126 178 132 103 539 do_close+324 0xc02689c4
120 98 96 75 389 do_select+368 0xc02689c4
93 82 93 70 338 wait_for_tcp_memory+797 (%ecx)
65 98 63 57 283 sys_open+132 0xc02689c4
65 51 68 59 243 sys_newstat+79 0xc02689c4
54 61 79 40 234 _fput+82 0xc02689c4
51 50 60 60 221 old_mmap+416 0xc02689c4
69 40 46 61 216 sys_fcntl+236 0xc02689c4
60 57 35 51 203 sock_map_fd+132 0xc02689c4
smaller is omitted.
In this kernel object, 0xc02689c4 is kernel_lock variable.
10 of top 11 spin-lock wait consumers are waiting kernel_lock.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:16 EST