httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject Re: [PATCH] murderous HUP
Date Tue, 18 Feb 1997 20:49:00 GMT
On Tue, 18 Feb 1997, Roy T. Fielding wrote:

> >What I would suggest is
> >
> >                long waittime = 4096;
> >
> >                while (((waitret = waitpid(pid, &status, WNOHANG)) == 0) &&
> >                        (waittime > 0) && (waittime < 3000000)) {
> >                       tv.tv_sec  = 0;
> >                       tv.tv_usec = waittime;
> >                       waittime << 3;
> >                       select(0, NULL, NULL, NULL, &tv);
> >                }
> 
> Urgle, never mind.  I've just discovered the usec clock on my Ultra1 runs
> in nanoseconds.  Going back to the modulo stuff, I've tested the
> following code:
> ==============================
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/time.h>
> 
> int main (void)
> {
>      int srv;
>      long waittime = 8192;
>      struct timeval tv;
> 
>      printf("Start\n");
>      while ((waittime > 0) && (waittime < 3000000)) {
>         printf("%d\n", waittime);
>         tv.tv_sec  = waittime/1000000;
>         tv.tv_usec = waittime%1000000;
>         waittime <<= 2;
>         srv = select(0, NULL, NULL, NULL, &tv);
>     }
>     printf("End\n");
>     exit(0);
> }
> ==============================
> and the result on my system is
> % time a.out
> Start
> 8192
> 32768
> 131072
> 524288
> 2097152
> End
> 0.00u 0.02s 0:02.88 0.6%
> 
> The bizarre thing is that without the modulo (just using tv_usec), it is
> 
> 0.00u 0.02s 0:00.74 2.7%

Similar on FreeBSD:

        2.87 real         0.00 user         0.00 sys

and:

        0.76 real         0.00 user         0.00 sys

I'm assuming it just takes tv_usec mod 1000000 internally so anything >1s
gets lost.  Ahh, nearly; in the BSD kernel (well... the FreeBSD one; ISTR
some slight differences in other BSDs WRT time handling) it is due to
timevalfix: 

static void
timevalfix(t1)
        struct timeval *t1;
{

        if (t1->tv_usec < 0) {
                t1->tv_sec--;
                t1->tv_usec += 1000000;
        }
        if (t1->tv_usec >= 1000000) {
                t1->tv_sec++;
                t1->tv_usec -= 1000000;
        }
}

Arguably a "feature".

Is there any reason to bother with a shift, or are compilers good enough
that they will implement multiplication by powers of two that way anyway? 

> 
> Anyway, 8192 and *4 seem to be reasonable values (on an Ultra 1, but the
> printfs will slow it down to average).

I'm not particularly concerned about the rest of the code or the real
runtime but just the sum of the series which is trivial enough to
estimate or calculate.  

On Tue, 18 Feb 1997, Roy T. Fielding wrote:

> Marc Slemko writes:
> >--- 1030,1086 ----
> >      for (i = 0; i < HARD_SERVER_LIMIT; ++i) {
> >  	int pid = scoreboard_image->servers[i].pid;
> >  
> >! 	if (pid != my_pid && pid != 0) { 
> >! 	    int waitret = 0,
> >! 		tries = 1;
> >! 
> >! 	    while (waitret == 0 && tries <= 4) {
> >! 		int waittime = 1; /* in usecs */
> >! 		struct timeval tv;
> 
> Ummm, there is no point in waiting for any less than 1000 usecs, since
> that's about how long it takes to execute a single instruction on a
> reasonably fast machine.  I suggest starting with 4096 and *8 on each pass.
> We don't want process swapping to steal all execution time from the children.

Sure there is.  After units fixed, it is true that the first few will be
so short that they will not be noticable and will have very bad
resolution, depending on the system, but the delays in the rest of the
code do make the loop long enough so I often do see it not exiting on the
first one but exiting soon (ie. a couple of interations) after.  It is,
however, a marginal case...

I agree with raising the starting value to 4096, but I'm not sure about
going to 4 as a multiplier instead of 2.  I think the cases at the higher
end of the scale benefit from having it at 2, while the lower end isn't
hurt that much.  If a processes is swapped out, it could take a few
seconds to swap it back in to kill it, so I like the ~4.3s that 2 gives as
opposed to the ~2.9 that 4 gives.


Mime
View raw message