Re: How the real-time priority take effect?

[Rohit Sharma <imreckless@xxxxxxxxx>]

On Wed, Nov 24, 2010 at 7:16 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

Hi Parmenides...

let's see what I can help here...

On Wed, Nov 24, 2010 at 03:21, Parmenides <mobile.parmenides@xxxxxxxxx> wrote:

> 1. The range of value that can be taken by rt_priority is from 1 to
> 99. I think, for a specific real-time process, it should be located at
> some level of runqueue which also ranges from 1 to 99.

Yes, AFAIK for each priority, there should be separate queue....thus
to avoid lengthy lookup.

Yes Mulyadi, each runqueue has queue of priorities.

When scheduling a process... scheduler checks goodness of process to determine next best candidate, and for real time processes it sets its goodness to a high value around 1000 making it most likely and best candidate to execute next.

This is determine by checking SCHED_OTHER....flag, if its not SCHED_OTHER then its a real time process....

I am pasting contents from this link :

http://oreilly.com/catalog/linuxkernel/chapter/ch10.html

How Good Is a Runnable Process?

The heart of the scheduling algorithm includes identifying the best candidate among all processes in the runqueue list. This is what the goodness( ) function does. It receives as input parametersprev (the descriptor pointer of the previously running process) and p (the descriptor pointer of the process to evaluate). The integer value c returned by goodness( ) measures the "goodness" of p and has the following meanings:

c = -1000

p must never be selected; this value is returned when the runqueue list contains only init_task.

c = 0

p has exhausted its quantum. Unless p is the first process in the runqueue list and all runnable processes have also exhausted their quantum, it will not be selected for execution.

0 < c < 1000

p is a conventional process that has not exhausted its quantum; a higher value of c denotes a higher level of goodness.

c >= 1000

p is a real-time process; a higher value of c denotes a higher level of goodness.

The goodness( ) function is equivalent to:

if (p->policy != SCHED_OTHER) 
       return 1000 + p->rt_priority; 
if (p->counter == 0) 
       return 0; 
if (p->mm == prev->mm) 
       return p->counter + p->priority + 1; 
return p->counter + p->priority; 

If the process is real-time, its goodness is set to at least 1000. If it is a conventional process that has exhausted its quantum, its goodness is set to 0; otherwise, it is set to p->counter + p->priority.

A small bonus is given to p if it shares the address space with prev (i.e., if their process descriptors' mm fields point to the same memory descriptor). The rationale for this bonus is that if p runs right after prev, it will use the same page tables, hence the same memory; some of the valuable data may still be in the hardware cache.

>So, the level
> of this real-time process should be determined by its rt_priority
> field. But, in scheduler_tick() function,
>
>                if ((p->policy == SCHED_RR) && !--p->time_slice) {
> 2446                        p->time_slice = task_timeslice(p);
> 2447                        p->first_time_slice = 0;
> 2448                        set_tsk_need_resched(p);
> 2449
> 2450                        /* put it at the end of the queue: */
> 2451                        requeue_task(p, rq->active);
> 2452                }
>
> when a process whose schedule policy is round robin uses up its time
> slice, the function put the process at the end of the level. The
> requeue_task() function is as follows:
>
>  587static void requeue_task(struct task_struct *p, prio_array_t *array)
>  588{
>  589        list_move_tail(&p->run_list, array->queue + p->prio);
>  590}
>
> It is obvious that when entering the runqueue again, the level of the
> process is determined by its dynamic priority. So, which one of the
> two priorities, namely real-time priority and dynamic priority, will
> determine a real-time process' level in a runqueue?
>

AFAIK, for real time process, the priority is always
fixed....hopefully CFS doesn't change that agreement...that's how
POSIX decides about real time process AFAIK.

> 2. I guess that for a real-time process, the dynamic priority may be
> equivalent to the real-time priority. If so, the dynamic priority
> shouldn't vary for the real-time process. But, when the process is
> being waken up, the try_to_wake_up() function will call the
> recalc_task_prio() function indirectly, which will cause the dynamic
> priority to change. Is my guess wrong?

yes, only for SCHED_OTHER process, the dyn prio is recalculated.

> 3. Eventually, I wonder what is the meaning of dynamic priority for a
> real-time process and whether there is some relationship between the
> dynamic priority and the real-time priority.

IMO, dynamic priority, in the meaning that "constantly adjusted prio
according to current system load" isn't a concern for a real time
process.

--
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ

-- 
Thanks and regards,
Rohit Sharma
Associate Software Engineer
Security Technology and Response
Symantec Corporation 
www.symantec.com