"Albert D. Cahalan" wrote:
>
> Viewing the worst case as 483 HZ makes it look awful.
> You could lose 3 clock ticks with a 1024 HZ clock.
Right.
And the information which I'm showing doesn't tell us how often this
tick loss will happen. So it would be useful to add a "count how many
times the traversal of this arc takes more than N microseconds"
feature. I doubt if I'll add this in the short term - 2.5 stuff. [ Does
Alpha _use_ this console and IDE code? ]
One thing I forgot to mention:
Jun has identified the code in exit_notify() as being a significant
blockage. I'm not sure what test case he was running (I looked at the
NIST tools and the build process exhausted my gnat-like patience). So I
ran this:
#include <stdlib.h>
main(int argc, char *argv[])
{
int i;
int n = 30;
if (argc > 1)
n = atoi(argv[1]);
for (i = 0; i < n; i++)
{
if (fork() == 0)
{
exit(0);
}
}
sleep(1);
}
It creates thirty zombies and then lets exit_notify() reparent them.
exit.c:363 -> exit.c:395 32 1.36 78.85 4.00
Eighty microseconds on a 400 MHz machine. I believe Jun was using a 233
MHz box.
So this remains a significant issue for those who are concerned about
interrupt latency. The console, NIC and IDE delays can be made to go
away by appropriate configuration and selection of peripherals but
exit_notify() will remain.
Of course, reaping thirty zombies is a pretty obscure corner case -
there will be other such cases, and if any of them exceed exit_notify()
then exit_notify() is not the problem! Always need to attack the worst
case in this game.
-- -akpm-- 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 : Fri Mar 31 2000 - 21:00:16 EST