[lkml]   [2004]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Fw: Re: Busy-wait delay in qmail 1.03 after upgrading to Linux 2.6
Haakon Riiser <> 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

> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:00    [W:0.022 / U:0.068 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site