2.6.0 schedule_tick question

2.6.0 schedule_tick question

[Der Herr Hofrat]

HI !

 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 ?

hofrat

Re: 2.6.0 schedule_tick question

[Davide Libenzi]

On Sat, 10 Jan 2004, Der Herr Hofrat wrote:

>  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.



- Davide

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
 

Re: 2.6.0 schedule_tick question

[Davide Libenzi]

On Sat, 10 Jan 2004, Der Herr Hofrat wrote:

> > 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.

Try to push a patch to Ingo. We already had a move_last_runqueue() in 2.4, 
but since now we have names like xxxx_task(), I believe rotate_task() 
sounds better.



- Davide