Re: Fw: Re: Busy-wait delay in qmail 1.03 after upgrading to Linux2.6

[Manfred Spraul]

Haakon Riiser <haakon.riiser@xxxxxxxxxx> wrote:

> What Qmail did was basically to use a named pipe as a trigger,
> where one program select()s on the FIFO file descriptor, waiting
> for another program to write() the FIFO.  Once select() returns,
> the listener close()s the FIFO (the data was not important,
> it was only used as a signal), does some work, then re-open()s
> the FIFO file, and ends up in the same select() waiting for the
> whole thing to happen again.
What drains the fifo?
As far as I can see the fifo is filled by the write syscalls, and 
drained by chance if both the reader and the writer have closed their 
handles.

>       for (;;) {
>                while ((fd = open("test.fifo", O_WRONLY | O_NONBLOCK)) < 0)
>                        ;
>                gettimeofday(&tv1, NULL);
>                if (write(fd, &fd, 1) == 1) {
xxx now a thread switch

>                        gettimeofday(&tv2, NULL);
>                        fprintf(stderr, "dt = %f ms\n",
>                                (tv2.tv_sec - tv1.tv_sec) * 1000.0 +
>                                (tv2.tv_usec - tv1.tv_usec) / 1000.0);
>                }
>                if (close(fd) < 0) {
>                        perror("close");
>  
If a thread switch happens in the indicated line, then the reader will 
loop, until it's timeslice expires - one full timeslice delay between 
the two gettimeofday() calls.

Running the reader with nice -20 resulted in delays of 200-1000 ms for 
each write call, nice 20 resulted in no slow calls. In both cases 100% 
cpu load.

--
   Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/