Messages in this thread | | | Date | Tue, 29 Sep 1998 10:37:07 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] scheduler patch, faster still |
| |
On Mon, Sep 28, 1998 at 01:32:42AM -0600, Larry McVoy wrote: > What you haven't shown is anything real about your application. You just > think that this will help but you don't know that. You don't know what > other things could occur to cause your RT process to not respond in time. > Victor pointed out a list of much larger problems and I'm sure the list > was incomplete.
I think I can give an example of an application needing bounded RT latency. This is not Richard's application.
We have a planned particle physics application, where a large pool of processors (a few hundreds or thousands) analyse events from a particle detector in order to find the interesting events.
First, the detectors feed data at a very high rate to some memory buffers. Prelimary electronics discards the most trivial non-events.
For each event after the electronic filter, a processor is chosen and sent a packet telling it to analyse the event, and which memory buffers to fetch data from. The processor must respond in a bounded time to that packet, by requesting and retrieving the data from the relevant memory buffers before the buffers overrun.
It isn't possible to simply send the data to the processor, because most of the time, not all the data is needed to make a decision. And sending all the data would be more than the network infrastructure could handle.
Experiments and theory have shown that one of the most important parameters in determining how much data can be handled, is round-trip latency. Simply buffering more data is not a solution, because buffering has its own overheads. (On a PC, the most obvious is cache pressure). Also we're talking about a very high data rate (thousands of gigabit rate links in parallel), and a small increase in latency corresponds to a rather large increase in buffering requirements.
Why isn't it all done with a special operating system? (Apart from the expense and maintainability issues). Because when the data is received by a processor, it goes through various filtering and processing stages that get successfully more complex (but at lower data rates), and that dataflow is best handled within a single machine, using ordinary programming techniques. These include having a decent operating system handy -- Linux seems like a good choice.
Multiple threads (one per active event on this processor) are used because of the different filtering layers: the later filtering stages are quite slow (involving lots of maths), but the initial stages must respond to the network in a timely fashion.
By timely, I mean that the RT latency of the thread which responds to new event packets and control packets must be bounded, or at least be within a bound with some measured probability quite close to 1.
It would be very helpful if the measured latency did not vary according to the non RT load, which of course depends on the precise formulation of the event filtering code, which is apt to keep changing for different experiments.
Latency is even in issue communicating within the analysis programs, because of cache locality effects. But that's a separate programming problem, not relevant to linux-kernel.
Hope this inspires!
-- Jamie
- 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/
| |