<div dir="ltr"><div>First of all thanks for the answer, I know that It isn't correct to make a task migrate from a cpu to another in a partitioned system, but It's a prototype for a more complex scheduler that allows a task to migrate only when particular conditions are met.</div>

<div><br></div><div>I understand my mistake, I will look under the hood hoping to find out how to avoid deadlock by calling the migrate_to function.</div><div><br></div><div>Best regards,</div><div>Sebastiano</div><div><br>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014/1/12 Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im"><br>
On 10 Jan 2014, at 19:29, Sebastiano Catellani <<a href="mailto:sebastiano.catellani@gmail.com">sebastiano.catellani@gmail.com</a>> wrote:<br>
<br>
> I'm modifying the pfp_schedule function of the sched_pfp.c file. The behavior that I want to obtain is to migrate a task from a cpu to another everytime that it is preempted by a task with higher priority.<br>
><br>
> With the following task set, I'd like that p2 migrates to the second cpu when it is preempted by p1 and migrates back to the first cpu when preempted by p3.<br>
><br>
> -p 1 -z 1 -q 3 5 20 //(p1)<br>
> -p 1 -z 1 -q 4 5 18 //(p2)<br>
> -p 2 -z 1 -q 3 3 20 //(p3)<br>
<br>
<br>
</div>Dear Sebastiano,<br>
<br>
the behavior that you describe sounds like a global scheduler. P-FP is a partitioned scheduler and not a good starting point to develop a global scheduler. If indeed you want to develop a global-like scheduler, please have a look at GSN-EDF instead.<br>


<div class="im"><br>
> This is the error I get when I execute the run_exps.py script:<br>
><br>
> =============================================<br>
> [ INFO: possible recursive locking detected ]<br>
> 3.10.5-litmus2013.1 #101 Not tainted<br>
> ---------------------------------------------<br>
> rtspin/1586 is trying to acquire lock:<br>
>  (&rt->ready_lock){......}, at: [<ffffffff81299940>] pfp_migrate_to+0x80/0x120<br>
><br>
> but task is already holding lock:<br>
>  (&rt->ready_lock){......}, at: [<ffffffff8129ba35>] pfp_schedule+0x35/0xab0<br>
><br>
> other info that might help us debug this:<br>
>  Possible unsafe locking scenario:<br>
><br>
>        CPU0<br>
>        ----<br>
>   lock(&rt->ready_lock);<br>
>   lock(&rt->ready_lock);<br>
><br>
>  *** DEADLOCK ***<br>
<br>
</div>Locking in a kernel such as Linux (and hence LITMUS^RT) is not transparent, meaning you need to understand which locks a function that you call may acquire. You can't just call a function that acquires locks from any context. Rather, you need to look at the code to understand when it is safe to call it.<br>


<br>
In your specific case, pfp_migrate_to() acquires per-CPU state locks. This means you can't call it while holding a per-CPU state lock (such as within the schedule() callback) unless you somehow make sure that deadlock is impossible. Linux's lockdep debugging aid tells you exactly this.<br>


<br>
Best regards,<br>
Björn<br>
<br>
<br>
_______________________________________________<br>
litmus-dev mailing list<br>
<a href="mailto:litmus-dev@lists.litmus-rt.org">litmus-dev@lists.litmus-rt.org</a><br>
<a href="https://lists.litmus-rt.org/listinfo/litmus-dev" target="_blank">https://lists.litmus-rt.org/listinfo/litmus-dev</a><br>
</blockquote></div><br></div>