Walter Hofmann <walter.hofmann@physik.stud.uni-erlangen.de> writes:
> On Sun, 27 Feb 2000, Ricky Beam wrote:
> >"bloat"? It's two lines of code in the process exit path. That adds, what,
> >four cpu cylces to process termination? That's not bloat. The price of
> >tracking process zombies in the kernel is far, far less than tracking it
> >in user land.
>
> It certainly is bloat.
>
> The process exit path is critical--it is called often and every cycle is
> important. Take a webserver: It can fork a process per request. Consider
> an SMP system: If you write to the same counter repeatedly with all CPUs
> you will get cache ping-pong effects which slow you down severely. All
> these things have to be considered.
I don't have a strong opinion either way on /proc/nzombies, but I am
certainly not convinced by this argument that it would cost too much.
Currently, the exit path always includes a for_each_task (in
forget_original_parent()). If the p_pptr/p_opptr stuff was rearranged so
that attaching a debugger to a process did not alter p_pptr (I think
Linus sugested something along these lines a few months ago for other
reasons), then this would not be necessary: The exiting parent could
just walk along its child list (processes without children wouldn't
even need to acquire the tasklist_lock). This would save far more
cycles than the atomic_inc needed for a zombie count would cost.
Given the concern expressed in this thread for the exit path, I'm
surprised no-one has taken care of forget_original_parent().
David Wragg
-
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:08 EST