Re: How the real-time priority take effect?

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

 



Hi...

On Wed, Nov 24, 2010 at 14:56, Parmenides <mobile.parmenides@xxxxxxxxx> wrote:
> Hi Santosa,
>
> My confusion is clarified by your reply. Furthermore, there are some
> details that deserves more considerations.

Glad I could offer some humble help...

> 2010/11/24 Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>:
...
> 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.

IMHO you already found the right code snippet to prove just that...congrats..

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

I found this function "rt_policy" in kernel/sched.c. I think you can
trace back on which functions that call this. I believe, this macro
will lead you on code snippet that might prove that for real time
process, time slice/priority is always  the same.

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



[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