[nptl] Re: SCHED_RR issue

[Sebastien Decugis <sebastien.decugis@ext.bull.net>]

> One of my favorite principle:
> In theory, there is no difference between theory and practice. 
> In practice, there is no similarity. 
> :-D :-D :-D 

:-) 
How true...

> 
> But I can't really imagine that scheld_yield() is broken. That's one
> of the most trivial syscall. Really. 

Ok ok :) I simply never looked at it :)

>  
> Let's check the kernel source right now ():
> /usr/src/linux-2.6.5-1.358/kernel/sched.c 
> 
> asmlinkage long sys_sched_yield(void)
> {
>         runqueue_t *rq = this_rq_lock();
>         prio_array_t *array = current->array;
> 
>         /*
>          * We implement yielding by moving the task into the expired
>          * queue.
>          *
>          * (special rule: RT tasks will just roundrobin in the active
>          *  array.)
>          */
>         if (likely(!rt_task(current))) {
>                 dequeue_task(current, array);
>                 enqueue_task(current, rq->expired);
>         } else {
>                 list_del(&current->run_list);
>                 list_add_tail(&current->run_list, array->queue +
> current->prio);
>         }
>         /*
>          * Since we are going to call schedule() anyway, there's
>          * no need to preempt:
>          */
>         _raw_spin_unlock(&rq->lock);
>         preempt_enable_no_resched();
> 
>         schedule();
> 
>         return 0;
> }
> 
> This looks just fine, I guess. Unless there are some issue with the spin
> lock...

Maybe the "likely(!rt_task(current))" returns a bad result? But anyway,
the sched_yield() routine is not proved not to work :) It's just one of
the possibilities to explain the test failure, IMO.


Seb.

-------------------------------
Sebastien DECUGIS
NPTL Test & Trace Project
http://nptl.bullopensource.org/

"You may fail if you try.
You -will- fail if you don't."


Liste de diffusion nptl
Pour se désinscrire : mailto:nptl_request@bullopensource.org?subject=unsubscribe