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

[William Lee Irwin III <wli@holomorphy.com>]

On Sat, Aug 28, 2004 at 09:45:46PM +0200, Roger Luethi wrote:
> Executive summary: I wrote a benchmark to compare /proc and nproc
> performance. The results are as expected: Parsing even the most simple
> strings is expensive. /proc performance does not scale if we have to
> open and close many files, which is the common case.
> In a situation with many processes p and fields/files f the delivery
> overhead is roughly O(p) for nproc and O(p*f) for /proc.
> The difference becomes even more pronounced if a /proc file request
> triggers an expensive in-kernel computation for fields that are not
> of interest but part of the file, or if human-readable files need to
> be parsed.
> Benchmark: I chose the most favorable scenario for /proc I could think
> of: Reading a single, easy to parse file per process and find every data
> item useful.  I picked /proc/pid/statm. For nproc, I chose seven fields
> that are calculated with the same resource usage as the fields in statm:
> NPROC_VMSIZE, NPROC_VMLOCK, NPROC_VMRSS, NPROC_VMDATA, NPROC_VMSTACK,
> NPROC_VMEXE, and NPROC_VMLIB.

These numbers are somewhat at variance with my experience in the area,
as I see that the internal algorithms actually dominate the runtime
of the /proc/ algorithms. Could you describe the processes used for the
benchmarks, e.g. typical /proc/$PID/status and /proc/$PID/maps for them?


-- wli