Re: Generalize /proc/fs/kernel/max-thread

Jamie Lokier (lkd@tantalophile.demon.co.uk)
Tue, 22 Dec 1998 16:45:07 +0000

On Mon, Dec 21, 1998 at 05:03:32PM +0100, Jean-Michel VANSTEENE wrote:
> Yes, I said the maximum number of tasks. Maybe you know that the "top"
> command, for instance, pre-allocates its internal table so as to collect
> process informations. The table size is found in tasks.h (NR_TASKS) at
> compile time. If you modify NR_TASKS and compile a new kernel, you must
> recompile the "top" command. I know you do that once, but if you have
> many different systems, it's not as easy as it could be.

Then top is broken, not the kernel.

> > (b) NR_TASK is going to be much larger than the actual number of
> > tasks, so it would be silly to preallocate. Consider if NR_TASK were
>
> Look the top command. It preallocates.

With NR_TASK == 100000, top will be very broken indeed.

> > (c) I'd expect approximately 0% performance improvement due to getting
>
> It is not a performance improvement. It is a system administrator's
> point of vue. A top command should be runable on all linux boxes. But
> it doesn't since it depends on a machine dependent value.

(a) Fix top.
(b) If top has to read a table size at run time (following your suggestion),
it might as well use the link count on /proc/.

-- Jamie

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/