Re: Question: RT schedular : task_tick_rt(struct rq *rq, structtask_struct *p) : decreases overhead when rq->nr_running == 1

["Mitchell Erblich" <erblichs@earthlink.net>]

Ingo Molnar and group,

First, RT/RR tasks are not deprecated.  This
change simply removes sched overhead while
only 1 RT/RR task is runable per rq.

The code size increase is minor and is a very
straightforward change..

THUS...

    My assumption is / was to hand you/Ingo Molnar this change
    because,
        * you have the latest scheduler git tree and do periodic
           pull requests, so I consider you the default scheduler
           maintainer ....   : ^ )
        * my scheduler tree is more developmental,
        * and I wish to first suggest minor changes over time to see
           what scheduler changes are more acceptable.

  Mitchell Erblich
----------------------


Ingo Molnar wrote:
>
> * Mitchell Erblich <erblichs@earthlink.net> wrote:
>
> > After
> >     p->time_slice = static_prio_timeslice(p->static_prio);
> >
> > Why isn't their a check like
> >     if  (rq->nr_running == 1)
> >          return;
> >
> > Which world remove the need for any recheduling or requeue'ing...
>
> your change is a possible optimization, but this is a pretty rare
> codepath because the overwhelming majority of RT apps uses SCHED_FIFO.
> Plus, the time_slice going down to 0 is a relatively rare event even for
> SCHED_RR tasks. And if we have only a single SCHED_RR task, why is it
> SCHED_RR to begin with? So this is on several levels an uncommon
> workload and by adding a check like that we'd increase the codesize. But
> ... no strong feelings against this optimization - if you send a proper
> patch we can apply it, it certainly makes sense from a logic POV.
>
>         Ingo
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/