Jos Visser wrote:
> I must say that I think calling the maintaining of the nzombies counter
> "bloat" is exaggerating.
It is, because it solves a highly specific problem while you could
implement a solution that solves a more general problem (or a class of
problems) that also includes the solution for your specific problem.
VMS illustrates quite nicely what this can lead to.
I would suggest that you try to implement a more general solution.
Two examples:
- implement a fast interface to extract essential ps and top
information (e.g. a single read returns well-defined fixed-length
records with text or binary content (your choice) for multiple or
all processes). This would solve the most visible problem of /proc,
namely the high processing overhead of top. The zombies counter
would be as simple as:
size = read(fd,huge_buffer,sizeof(huge_buffer));
zombies = 0;
for (i = PROC_STATE_OFFSET; i < size; i += RECORD_LENGTH)
if (huge_buffer[i] == ZOMBIE_STATE) zombies++;
- go one step back and ask yourself why zombies are a problem. The
probable answer is because they overflow your process table. A
general solution that prevents a process tree from growing too
big would also limit the impact of zombies (and solve some of the
problems and fork bombs, etc.). So you could implement a resource
limit for the number of children spawned by a process and its
children. Some design considerations:
- needs shared counter, which works also after death of parent
(possible solution: maintain linked list of processes sharing
the same limit)
- if a process sets its limit, this new shared limit could either
be taken away from the previous shared limit (and returned when
the last process in this subtree has dies), or the minimum of
all the limits set by ancestors is used (*)
(* e.g. given
foo(limit=10)-+-bar()
`-xyzzy(limit=3)
In approach 1), the constraint for additional children would
be xyzzy <= 3 && foo+bar <= 5
In approach 2), the constraint for additional children would
be xyzzy <= 3 && foo+bar+xyzzy <= 8)
- probably needs to allow privileged processes to start a new,
independent limit group
There are probably useful examples for such designs in other Unix
systems. A look at VMS may also be worthwhile. (I've forgotten the
exact rules here. Chances are that you can pick from a large set of
them ;-)
None of these more general solutions should be much more complex to
implement than a correct nzombies, but they would have uses far beyond
the counting of zombies created by programs most people wouldn't even
install on their systems.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, ICA, EPFL, CH werner.almesberger@ica.epfl.ch / /_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/- 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:09 EST