Messages in this thread | | | Date | Sun, 29 Aug 2004 19:52:45 +0200 | From | Roger Luethi <> | Subject | Re: [BENCHMARK] nproc: netlink access to /proc information |
| |
On Sun, 29 Aug 2004 10:20:22 -0700, William Lee Irwin III wrote: > > ==> 10000 processes: top -d 0 -b > /dev/null <== > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > > Profiling through timer interrupt > > samples % image name symbol name > > 35855 36.0707 vmlinux get_tgid_list > > 9366 9.4223 vmlinux pid_alive > > 7077 7.1196 libc-2.3.3.so _IO_vfscanf_internal > > 5386 5.4184 vmlinux number > > 3664 3.6860 vmlinux proc_pid_stat > > get_tgid_list() is a sad story I don't have time to go into in depth. > The short version is that larger systems are extremely sensitive to > hold time for writes on the tasklist_lock, and this being on scales > not needing SGI participation to tell us (though scales beyond personal > financial resources still).
I am confident that this problem (as far as process monitoring is concerned) could be addressed with differential notification.
> > ==> /prod/pid/statm (2x) for 10000 processes <== > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > > Profiling through timer interrupt > > samples % image name symbol name > > 7430 9.9485 libc-2.3.3.so _IO_vfscanf_internal > > 6195 8.2948 vmlinux __d_lookup > > 5477 7.3335 vmlinux task_statm > > 5082 6.8046 vmlinux number > > 3227 4.3208 vmlinux link_path_walk > > scanf() is still very pronounced here; I wonder how well-optimized > glibc's implementation is, or if otherwise it may be useful to > circumvent it with a more specialized parser if its generality > requirements preclude faster execution.
I'd much rather remove unnecessary overhead than optimize code for overhead processing. Note that number() takes out 7% and that's the _kernel_ printing numbers for user space to parse back. And __d_lookup is another /proc souvenir you get to keep as long as you use /proc.
> > ==> 27 nproc fields for 10000 processes, one process per request <== > > CPU: CPU with timer interrupt, speed 0 MHz (estimated) > > Profiling through timer interrupt > > samples % image name symbol name > > 7647 25.0894 vmlinux __task_mem > > 2125 6.9720 vmlinux find_pid > > 1884 6.1813 vmlinux nproc_pid_fields > > 1488 4.8820 vmlinux __task_mem_cheap > > 1161 3.8092 vmlinux mmgrab > > It looks like I'm going after the right culprit(s) for the lower-level > algorithms from this.
Well __task_mem is promiment here because I don't call other computation functions. vmstat ain't cheap, and wchan is horribly expensive if the kernel does the ksym translation. Etc. pp.
Roger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |