Messages in this thread | | | Date | Mon, 26 Jul 1999 08:40:59 +1000 | From | Richard Gooch <> | Subject | Re: real-time threaded IO with low latency (audio) |
| |
yodaiken@chelm.cs.nmt.edu writes: > On Sun, Jul 25, 1999 at 08:20:06PM +0200, David Olofson wrote: > > > 3. any other trap or error condition that puts us in K mode. > > > > Does this need to be handled without losing the RT timing, or is it > > "just" a matter of handling it to keep RT an error condition from > > causing a bad crash? > > Linux may die horribly if it allows the RT task to enter kernel mode. > So we would have to put guards on all kernel entry points > if running rt process (note current will not be useful) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Why not? We could add a flag bit to task_struct that means "RT process". So kernel entry points would just need to check current->is_rt
> then > call rt scheduler with error indication > > the rt scheduler would then mark the current rt task with an error > condition and let it handle it. We'd bypass the linux scheduler entirely > and would have to add a RT call > run_user_mode_process(p);
Why not move the process to a Linux run queue on kernel traps? This would take the process off the RTL run queue and would cause RTL to call rtl_schedule() (or equivalent). This would (possibly) cause Linux to be scheduled and thus normal kernel processing would continue.
> Doesn't sound so bad now. A error would basically loose RT > functionality: that seems ok.
Dropping RTL priority when you enter kernel mode is fine.
> But it would require a bigger Linux patch.
Indeed.
> I described this idea to Linus and it made him deeply unhappy.
Precisely what made him unhappy? The requirement to patch all kernel entry and exit points? Or just the concept of dropping RTL priority?
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/
| |