Re: [patch] sched_yield in 2.2.x

[Ivan Schreter]

Hello,

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?

Ivan Schreter
[e-mail]