On Wed, Nov 24, 2010 at 7:16 AM, Mulyadi Santosa <[email protected]>wrote:
> Hi Parmenides... > > let's see what I can help here... > On Wed, Nov 24, 2010 at 03:21, Parmenides <[email protected]> > 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* = -1000p must never be selected; this value is returned when the runqueue list contains only init_task. *c* = 0p 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* < 1000p is a conventional process that has not exhausted its quantum; a higher value of c denotes a higher level of goodness. *c* >= 1000p 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 [email protected] > 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
