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

[Roger Luethi <rl@hellgate.ch>]

On Sun, 29 Aug 2004 12:17:07 -0700, William Lee Irwin III wrote:
> > In glancing at the get_tgid_list() I see it is careful to only pick off
> > 20 (PROC_MAXPIDS) slots at a time.  But elsewhere in the kernel, I see
> > several uses of "do_each_thread()" which rip through the entire task
> > list in a single shot.
> > Is there a simple explanation for why it is ok in one place to take on
> > the entire task list in a single sweep, but in another it is important
> > to drop the lock every 20 slots?
> 
[...]
> Introducing another whole-tasklist scan, even if feasible, is probably
> not a good idea.

I'm not sure whether I should participate in that discussion. I'll risk
discrediting nproc with wild speculations on a subject I haven't really
looked into yet. Ah well...

As far as nproc (and process monitoring) is concerned, we aren't really
interested in walking a complete process list. All we care about is
which pids exist right now. How about a bit field, maintained by the
kernel, to indicate for each pid whether it exists or not? This would
amount to 4 KiB by default and 512 KiB for PID_MAX_LIMIT (4 million
processes). Maintenance cost would be one atomic bit operation per
process creation/deletion. No contested locks.

The list for the nproc user could be prepared based on the bit field
(or simply memcpy'd), no tasklist_lock or walking linked lists required.

What am I missing?

Roger