Re: itimer again (Re: [PATCH] RTC: Add mmap method to rtc character driver)

[Theodore Tso <tytso@mit.edu>]

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