<div dir="ltr">I see... well, considering this is just an academic evaluation I guess some degree of idealization is allowed. The objective is to come up with practical realizations of a few power-aware sched. algorithms (which usually are based on "classic" multiprocessor sched. algorithms, e.g. P-EDF, G-EDF) and assess their performance trends in terms of power consumption. Plus, at this stage it is intended to only provide support for simple synchronous, periodic tasks, so this is not much of a problem =)<div><br></div><div>About rtspin, I had not seen its source code and so I didn't know how it really operates, sorry about that.</div><div><br></div><div>I'm concerned with the following: in the real-time scheduling literature, lowering the processor frequency results in a prolonged execution (i.e. jobs' runtimes are inversely proportional to frequency). I think rtspin should be ok for simulating such increase when the scheduling policy lowers the processor frequency offline (a single speed modification before release and that's it) by passing the scaled wcet parameter to rtspin (thus making the rt task run longer). But how to properly enforce, or at least mimic this behavior online I'm not sure...</div><div><br></div><div>The processor frequency could change at any point in the schedule, so the runtime of every job would have to stretch/shrink accordingly. I've quickly gone through a paper by Dr. Erickson form UNC in which the concept of "virtual time" is employed. However, an interface between user/kernel-space had to be used for controlling speed changes. Another thought was to use the recently added task_param_change callback for applying changes during scheduling events, but I'm not so sure if this would be useful for making changes at the job level. Lastly, I considered writing custom real-time tasks that performed some computation (instead of just spinning) using liblitmus such that freq. changes actually modified their runtimes. The problem I see with this is that I wouldn't have much control over the task exec. time as provided by rtspin. Does anyone with more expertise than me has any suggestions? Possibly some quick hack or workaround that didn't involve considerable changes to the LITMUS^RT core?</div><div><br></div><div>Sorry if this is getting too long, I just have one last question: may I ask what's the standard way of benchmarking plugins in LITMUS^RT? I was under the impression that synthetic sets of real-time tasks (based on rtspin) were generated and scheduled, traces analyzed in a posterior step, but given your comments on the rtspin program now I'm not so sure.. For example, looking at the evaluation procedure provided for the apa scheduler, I see that it basically consists in launching several rtspin tasks and collecting scheduling traces. The python script provided for running tests on plugins in the github repo does a similar job.</div><div><br></div><div>Thank you so much for your help. Regards!!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 14, 2017 at 1:37 AM, Björn Brandenburg <span dir="ltr"><<a href="mailto:bbb@mpi-sws.org" target="_blank">bbb@mpi-sws.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 14. Jun 2017, at 06:07, Gabriel Lozano <<a href="mailto:gabrilozano90@gmail.com">gabrilozano90@gmail.com</a>> wrote:<br>
><br>
> I'm inserting this functionality in the release_jobs() callback used by psnedf_domain_init(), and the job_completion() helper function called by psnedf_schedule(). However, during task release, I'm visiting each node in the release_heap for updating their load (as done in the p-fp plugin), and are protecting the portion of code that gets the max. load among all m cpus with a global lock (for avoiding concurrent updates), so additional overheads are expected. Is this design worthwhile?<br>
<br>
</span>For moderately sized task sets (i.e., anything not hundreds of tasks), that’s going to be fine overhead-wise.<br>
<br>
However, it also means that your plugin will work only for (a) periodic tasks that (b) call sleep_next_period() in liblitmus. For example, run rtspin with the -T option, or trigger rtspin sporadically with the -S options, and see what happens.<br>
<br>
Whether this is an issue depends on your goals. If you are primarily interested in obtaining an academic prototype that is suitable for some controlled evaluation workloads that you know will satisfy (a) and (b), then this is probably be an acceptable limitation. If, however, you want your plugin to be useful with arbitrary Linux tasks, then this approach is not going work.<br>
<br>
For example, have a look at the P-RES plugin, which is designed to support real-world Linux tasks. It is completely reservation-based and does not use (the older) rt_domain_t code at all and instead treats all wakeups/job completions as regular suspensions, which is more in line with how the rest of Linux works.<br>
<span class=""><br>
> Follow-up: I've compiled LITMUS^RT with freq. scaling enabled, have changed (offline) the freq. of all processors to the max. and min. values (during different experiments), and have run a light test under these settings using P-EDF. However, to my surprise, the produced schedules using the max. and min. speeds are identical (tasks run times are pretty much the same), whereas I was expecting a certain performance degradation of some sort. My question is: what am I supposed to expect when changing the speed of the processors at offline/online? Are there portions of code sensitive to speed changes?<br>
><br>
> Could someone help me interpret this behavior I'm observing?<br>
<br>
</span>Are you using rtspin? It spins based on how much time it has consumed, so changing processor frequency is not going to affect its runtime: if you make the processor faster, it will simply spin for more iterations. rtspin is primarily a debugging and prototyping tool, and not a high-fidelity workload simulator that reacts plausibly to changes in processor/memory/cache/<wbr>whatever configuration.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Björn<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<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" rel="noreferrer" target="_blank">https://lists.litmus-rt.org/<wbr>listinfo/litmus-dev</a><br>
</div></div></blockquote></div><br></div>