[lkml]   [2004]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BENCHMARK] nproc: netlink access to /proc information
> 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

Thanks, Roger and William, for your good work here. I'm sure that SGI's
big bertha's will benefit.

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?

From the code and nice comments, I see that:
(1) the work that had to be done by proc_pid_readdir(), the caller of
get_tgid_list(), required dropping the task list lock, and
(2) so the harvested tgid's had to be stashed in a temp buffer.

So perhaps the reason for not doing this in a single pass is:
(3) it was not doable or not desirable (which one?) to size that temp
buffer large enough to hold all the harvested tgid's in one pass.

But my understanding is losing the scent of the trail at this point.

I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <> 1.650.933.1373
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:05    [W:0.092 / U:1.824 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site