Re: How the real-time priority take effect?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Santosa,

My confusion is clarified by your reply. Furthermore, there are some
details that deserves more considerations.

2010/11/24 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>:

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

Now that the dynamic priority is equivalent to the real-time priority,
namely that p->prio == p->rt_priority, for a real-time process, we can
make sure that the dynamic priority shouldn't be adjusted fot this
process. As for one kernel control path, namely schedule() ->
recalc_task_prio(), it is the case indeed. This can be seen in the
following code in __sched schedule()

2783        if (!rt_task(next) && next->activated > 0) {
2784                unsigned long long delta = now - next->timestamp;
2785
2786                if (next->activated == 1)
2787                        delta = delta * (ON_RUNQUEUE_WEIGHT * 128
/ 100) / 128;
2788
2789                array = next->array;
2790                dequeue_task(next, array);
2791                recalc_task_prio(next, next->timestamp + delta);
2792                enqueue_task(next, array);
2793        }

we can see that only if the next process is a normal process and in
TASK_INTERRUPTIBLE or TASK_STOOPED state, the recalc_task_prio() get
its running to update the dynamic priority of next.

But, for another kernel control path, namely try_to_wake_up() ->
activate_task() -> recalc_task_prio(), it seems that there is no any
conditions set in this path to ensure that a real-time process'
dynamic priority can not be updated. Of course, there may be some
other kernel control path neglected by me. If so, the goal to maintain
the dynamic priority fixed for a real-time process can not be achieved
readily.

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



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux