I'm not subscribed, so replies please CC: to me.
> > (I changed it to -1 just to be sure this process isn't accidentally
> > picked when there is other process to run - maybe I'm wrong here, but
> > 2.4.5 gives it also goodness -1, so it should be OK).
> The -1 is better than 0 since 0 will trigger a recalc if no other tasks
> have any time left. (Or do you want this to happen? As you have it,
> the yielding task will get control if all other tasks in the run list
> have zero counters. Seems like the recalculation should happen to find
> a better candidate.)
Yes, I think that is OK according to specs. If we get a recalc, then we get
control anyway, since we have some time left when calling sched_yield(). Or am
I wrong here? Anyway, it performs quite well in tests...
> The real problem with this patch is that if a real time task yields, the
> patch will cause the scheduler to pick a lower priority task or a
> SCHED_OTHER task. This one is not so easy to solve. You want to scan
> the run_list in the proper order so that the real time task will be the
> last pick at its priority. Problem is, the pre load with the prev task
> is out of order. You might try: http://rtsched.sourceforge.net/
Well, let's look at it this way: real-time tasks may want to yield when they
are waiting for something to happen that is not system-controlled (like a
user-mode spinlock). Otherwise they would be waiting in (un)interruptible sleep
controlled by the kernel. So when a RR task yields, then it yields because some
condition isn't met. So it has to wait anyway. Scheduling a lower
priority task in the meantime will do only good to the system IMHO.
I know this is not quite standard, but to make it work standards-compliant
(task will continue to run if there are no other tasks blabla) it is enough to
check # of runnable tasks in the run queue in sys_sched_yield() and return
immediately if we are the only task running. I can implement that. Anybody
thinks it's worth it?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/