Re: Scheduling Times --- Revisited
Larry McVoy (lm@bitmover.com)
Tue, 29 Sep 1998 03:20:59 -0600
Olivier Galibert <galibert@pobox.com>:
: On Tue, Sep 29, 1998 at 12:07:13AM -0600, Larry McVoy wrote:
: > : So what do you suggest as an alternative? Scenario: 10 kHz interrupt
: > : from device, new value needs to be written within 50 us. Device driver
: > : reads data, wakes up RT process. RT process reads data from driver,
: > : computes and writes new value, writes recent value to SHM and blocks
: > : on read again.
: > : SHM value is read at a much lower rate by low-priority threads. Some
: > : of these can safely lag behind, so they don't even need RT priority.
: > : Running on a 386DX33 where a switch takes 12.3 us (no extra processes
: > : on the run queue) and each extra process on the run queue adds another
: > : 7.4 us. Add interrupt latency, work to be done, syscall overheads and
: > : interrupt disabling sections, and we're getting close to 50 us. Add
: > : a few monitor threads (SCHED_OTHER), and we go past that.
: >
: > Modify the driver's interrupt routine to get the data, put it in a buffer,
: > and wake up a user level process when the buffer gets full, meanwhile
: > switching to a new buffer. I don't mean to be condescending, but this
: > is really basic producer/consumer type event gathering. Haven't you
: > ever done this before? I just assumed that anyone who has done kernel
: > performance work has had to gather event data from the kernel - how else
: > would you do it without completely disturbing other system activity?
:
: What about the "new value needs to be written within 50 us" part?
: Except by moving the new value computing in the interrupt driver
: routine I don't see how buffering may help.
It wasn't clear to me that the new value needed to be written back to the
device. But either way, it doesn't matter. Sure, if you need to, put the
computation in the interrupt handler. What's the big deal?
It just boggles my mind that someone would seriously propose to wake up
a process to read an int and write an int and expect that to perform
well.
: Actually, outside of this read-compute-write tight cycle, he says that
: they _do_ buffer the data.
As far as I can tell that's like building a stdio I/O buffering routine
that fills the buffer by calling read(f,&c,1) over and over rather than
just one big read().
-
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/