Hi there.
>> 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++;
More realistically:
maxsize = get_process_count() + 100;
buffer = (ps_rec **) malloc(sizeof(ps_rec * maxsize);
size = get_process_data(buffer);
zombies = 0;
for (i=0; i<size; i++)
if (buffer[i].state == ZOMBIE)
zombies++;
No matter how large you make the buffer, if it's not geared to
the current number of processes, it's ripe for a buffer over-run
attack...
> - go one step back and ask yourself why zombies are a
> problem. The probable answer is because they overflow
> your process table.
Am I right in thinking that once a process achieves Zombie
status, it tays as an unschedulable zombie until killed?
If so, then an obvious solution would be to move zombies out of
the process table into a separate linked list (or perhaps into
the /proc/nzombies file) and thus free up the process slots they
used to occupy.
That would probably produce a kernel speedup as well, as the
kernel wouldn't need to scan through the zombies checking they
are zombies when it schedules...
Best wishes from Riley.
* Copyright (C) 1999, Memory Alpha Systems.
* All rights and wrongs reserved.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* http://www.memalpha.cx/Linux/Kernel/
-
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:14 EST