Messages in this thread | | | Date | Tue, 20 Jan 2004 19:33:17 +0100 | From | Manfred Spraul <> | Subject | Re: Fw: Re: Busy-wait delay in qmail 1.03 after upgrading to Linux 2.6 |
| |
Haakon Riiser <haakon.riiser@fys.uio.no> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |