Re: 2.6.0 schedule_tick question

[Der Herr Hofrat]

> 
> >  in 2.6.0 kernel/sched.c scheduler_tick currently the 
> >  case of rt_tasks for SCHED_RR is doing
> > 
> > 	if ((p->policy == SCHED_RR) && !--p->time_slice) {
> > 			...
> >                         dequeue_task(p, rq->active);
> >                         enqueue_task(p, rq->active);
> > 
> >  which is:
> > 
> > static inline void dequeue_task(struct task_struct *p, prio_array_t *array)
> > {
> >         array->nr_active--;
> >         list_del(&p->run_list);
> >         if (list_empty(array->queue + p->prio))
> >                 __clear_bit(p->prio, array->bitmap);
> > }
> > 
> > static inline void enqueue_task(struct task_struct *p, prio_array_t *array)
> > {
> >         list_add_tail(&p->run_list, array->queue + p->prio);
> >         __set_bit(p->prio, array->bitmap);
> >         array->nr_active++;
> >         p->array = array;
> > }
> > 
> >  looking at these two functions this looks like quite some overhead as it
> >  actually could be reduced to:
> > 
> >         list_del(&p->run_list);
> > 	list_add_tail(&p->run_list, array->queue + p->prio);
> > 
> >  for the rest I don't see any effect it would have ?
> 
> Yes, we could have a rotate_task() function but the impact is basically 
> zero because of the little overhead compared to the frequency of the 
> operation.
>
ok - well maby someone wants to drop it in any way as its
trivial and actually it would be easier to read if the function name
were rotate_task and not dequeue/enqueu to implement RR behavior.

thx !
hofrat
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/