The story so far:
Jos Visser (that's me) proposed to put a configurable option in the
kernel to count the number of zombies in the system and export that
information through a file in /proc (/proc/nzombies). The underlying
reason was to make this particular system information quickly available
to applications that want to monitor the system's health.
Some people objected to this because it would "bloat" exit() with an
inc++ and release() with a dec--. I think that calling this "bloat" in
an era where web servers are sinking from userland into the kernel is
stretching it a wee bit (however, others disagree with me here).
Furthermore I would suggest that since it is (would be) configurable,
everybody can choose whether or not to incur this penalty.
Other people suggested various ways to perform the zombie count in shell
script. My whole point in posting the /proc/nzombies suggestion in the
first place was that the kernel is uniquely placed to perform this count
not only factors, but whole magnitudes, more efficiently. It's not just
a case of moving code from userland to the kernel, it's doing it in the
kernel because there I can solve this particular problem in a way I can
nowhere else in the system.
Then, would it be fair to slow down exit() for a feature that will not
be used by the majority of users? Again, if it's configurable, anyone
can make their own choices. On the other hand, if these type of very
minor pieces of functionality would start being configurable options,
the number of CONFIG_xx options would probably soon go through the roof!
However, this would probably not be the first function the kernel
contains that is geared toward a particular type of user/usage.
Many people questioned why I would care, and why I couldn't just patch
the zombie generating software in the first place. My answer there is
that in my experience in implementing system monitoring for various
types of Unix systems over the years have led me to making the zombie
check a "default" thing to be monitored for. You just would not believe
some of the (closed source) software one comes across. Changing or
dumping the software at fault is usually not acceptable for business
reasons.
One (interesting) comment was that the feature was not general enough,
and should maybe be changed into a feature to obtain the entire process
table quickly and efficiently from a userland program, thereby solving a
bunch of other problems as well. I find that an interesting approach,
and one that I'll ponder on for some time. Would this be "bloat" as
well? Who knows.....?
Anyways,
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()).
++Jos
-- Are you game for the SANE 2000 edition of the InSANE quiz? See http://www.nluug.nl/sane/.- 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:10 EST