a well-know effect in Linux 2.0 was delayed scheduling when a process
was using select to wait for an event. Only after the next timer
interrupt rescheduling was initiated (if I remember the details
correctly).
Now someone said it'll all be different in Linux 2.2, and I believed
it; until yesterday:
I have a really precise external pulse generator (read "GPS"), and
I've feed characters every second from the GPS to the serial port.
Measuring the time when the process was scheduled, I still saw the
old and well-known "sawtooth": Instead of slowly drifting away in one
direction, the clock seems to have a "modulo-1-tick jump", most
likely caused by the event when the character receive time crosses a
tick event.
(In my previous experiments I had always used a simulated generator
derived from the same quartz, so that the problem never appeared).
I'm not yet sure what has to be done, but I'm VERY sure that
something has to be done. I get messages from time to time saying:
"My old SPARCstation with 16 MHz (Solaris running, of course) can
keep time better than my Pentium-200 with Linux". I don't believe
that it's a hardware issue.
I'm also not sure whether the driver would have to initiate
"immediate rescheduling" if something "interesting" happens. But when
doing my experiments the machine was rather idle, so most likely the
process to run wile waiting for I/O was the idle process. Fixing that
problem might increase the CPU saturation, therby giving benefit to
every one.
Ideas or insight?
Regards,
Ulrich
-
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/