2.6.0 schedule_tick question

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 ?

Quoted 30 lines

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:

Quoted 4 lines

        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.

Quoted 4 lines

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.