Messages in this thread | | | Date | Sun, 30 Jul 2006 10:33:42 -0400 | From | Theodore Tso <> | Subject | Re: itimer again (Re: [PATCH] RTC: Add mmap method to rtc character driver) |
| |
On Sat, Jul 29, 2006 at 06:39:36PM -0700, Bill Huey wrote: > On Sat, Jul 29, 2006 at 06:22:59PM -0700, Nicholas Miell wrote: > > On Sat, 2006-07-29 at 18:00 -0700, Bill Huey wrote: > > > Think edge triggered verse level triggered. Event interfaces in the Linux > > > kernel are sort of just that, edge triggered events. What RT folks generally > > > want is control over scheduling policies over a particular time period in > > > relation to a scheduling policy. A general kernel event interface isn't > > ^ Did you mean to say timer here? > > No, I really ment scheduling.
Bill,
Do you mean frequency-based scheduling? This was mentioned, IIRC, in Gallmeister's book (Programming for the Real World, a must-read for those interested in Posix real-time interfaces) as a likely extension to the SCHED_RR/SCHED_FIFO scheduling policies and future additions to the struct sched_policy used by sched_setparam() at some future point.
The basic idea here is that if you have some task which is cyclic in nature, what might be useful would be to tell the scheduler that a particular thread should be woken up every at a specific cyclic time; and that thread promises it will only run for a certain amount of time, and before that time expires, it will finish running. If it doesn't, this is considered an overrun situation, and a number of different things can happen at that point, including a signal which might or might not kill the process, merely recording the event that there was an overrun. It would be possible to have and soft and hard overrun limits where you record the number and amount of time exceeded of soft overruns, and upon a thread using up its promised time quantuum plus the hard overrun limit, it gets a signal.
Since the scheduler knows when the cyclic tasks need to run, and how much time they promise to take, in theory it might be able to do a better job scheduling the threads, particularly if it knows that certain threads can tolerate being scheduled earlier or later within some time boundaries (which means even more fields in the struct sched_policy). At least, that's the theory. The exact semantics of what would actually be useful to application is I believe a little unclear, and of course there is the question of whether there is sufficient reason to try to do this as part of a system-wide scheduler. Alternatively, it might be sufficient to do this sort of thing at the application level across cooperating threads, in which case it wouldn't be necessary to try to add this kind of complicated scheduling gorp into the kernel.
In any case, I don't think this is particularly interesting to the X folks, although there may very well be real-time applications that would find this sort of thing useful.
Regards,
- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |