Re: Scheduling Times --- Revisited
Richard Gooch (rgooch@atnf.csiro.au)
Tue, 29 Sep 1998 22:29:06 +1000
Larry McVoy writes:
> 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.
Why do you think I wrote: "computes and writes new value"?!?
> But either way, it doesn't matter. Sure, if you need to, put the
> computation in the interrupt handler. What's the big deal?
Well, for one thing we don't want to put this into a driver. We don't
have to do that under pSOS+.
Also, the computation algorithm may change depending on other
conditions. And the computation is dependent on a fair bit of state in
the application.
The value also needs to be written into SHM. That allows other threads
to grab the data as they see fit and not have to go through a syscall.
Putting all this into a driver is awful. It also means more time is
spent in kernel mode, which we want to avoid, as that blocks
higher-priority processes.
It also makes the applications less portable to other OSes (things we
have to live with, I'm afraid).
> 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.
I didn't say it was an int: it could be a small block of data. Either
way, it doesn't matter. We can do this fine under pSOS+.
This is a reasonable thing to do, and is fairly typical of RT
applications.
Regards,
Richard....
-
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/