Re: [BENCHMARK] nproc: netlink access to /proc information

[Roger Luethi <rl@hellgate.ch>]

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