"A month of sundays ago Jos Visser wrote:"
> One (interesting) comment was that the feature was not general enough,
THis is the only valid objection, as far as I can see.
BTW, are people really serious about this "bloat" via an inc in the
process exit path? Why? The only thing I can vaguely imagine is that
slowing down the rate at which processes are reaped might divert a
whole 3 or 4 machine instructions from some more deserving process.
Well, big deal? If reaping dead processes is a DOS opportunity,
consider how much it cost to start them! If really concerned, configure
a kernel thread to do the final reaping at intervals :-) This will lead
to lots of nice zombies to count!
> The /proc/nzombies "feature" is obviously not a very important one.
> There are plenty ways to get this information (including a very nice
> loadable module nzombies.o that does the same, less efficiently, but it
> does not patch exit()/release()).
What you want to do is provide a snapshot of lots of volatile kernel
information on demand. Counting zombies is just an example. The
problem you want to solve is that you can't get accurate info because
you have to traverse proc structures, which takes time. Solutions?
You have proposed gathering the information in kernel and displaying
it on demand. But this is not a generic approach.
Peter
-
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/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:11 EST