Re: 2.6.0 schedule_tick question
From: Der Herr Hofrat
Date: Sun Jan 11 2004 - 12:24:53 EST
>
> > 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/