[LITMUS^RT] Question about how to specify dedicated cores to G-EDF and the relative deadline

[Glenn Elliott]

(As a matter of style, we prefer to follow the Linux mailing list practice of putting email replies at the bottom of email threads, rather than the top.  See my response below.  Also, there is a note at the bottom I want everyone new to Litmus to read.)

On Dec 13, 2013, at 11:34 PM, Luo, Zheng <luozheng at wustl.edu> wrote:

> Thanks for the reply. I think I get a little bit confused here. I tried to use the set cpu mask and set cpu affinity on Litmus, however it does not work. It seems that the Litmus ignored that.
> 
> Also how can I use the “Release Master”? Does that mean I have to the reconfiguration and then recompile the kernel to do that?
> 
> Zheng Luo
> 
> From: litmus-dev-bounces at lists.litmus-rt.org <litmus-dev-bounces at lists.litmus-rt.org> on behalf of Glenn Elliott <gelliott at cs.unc.edu>
> Sent: Friday, December 13, 2013 9:15 PM
> To: litmus-dev at lists.litmus-rt.org
> Subject: Re: [LITMUS^RT] Question about how to specify dedicated cores to G-EDF and the relative deadline
>  
> 
> On Dec 13, 2013, at 11:00 PM, Luo, Zheng <luozheng at wustl.edu> wrote:
> 
>> Hi everyone,
>> 
>> I have a question about how to choose dedicated group of cores on Litmus running G-EDF. For example, if my machine have 4 cores, I want to reserve core 0 for the Operating system, and core 1-3 to the rt-thread which can do the work. How can I do that? I tried the C-EDF, however used the L1,L2,L3 caches to do the division. I was wondering how can I do the division manually in the G-EDF?
>> 
>> Also, I have a question about the relative deadline, I think the normally the G-EDF should have the absolute deadline. Does the Litmus automatically convert relative deadline to the absolute deadline when using the G-EDF?
>> 
>> Thanks, Looking forward to the reply.    
>> 
>> 
>> Zheng Luo
> 
> Hi Zheng,
> 
> I think you can accomplish what you want to do by using a “Release Master”.  This is enabled by asserting the CONFIG_RELEASE_MASTER compile-time option under the “Scheduling” menu.  This will reserve CPU0 (aka the “Release Master”) for handling release interrupts for G-EDF running on the remaining CPUs.  You can also run general code on the release master CPU, assuming you have properly configured CPU affinity masks for those processes/threads.
> 
> All EDF schedulers, including G-EDF, always uses a job’s absolute deadline to prioritize scheduling.  A relative deadline (a task attribute, not a job attribute) scheduler would be something like Deadline-Monotonic scheduling— tasks with smaller relative deadlines have higher priority.  Implementing your own Deadline-Monotonic scheduler is not hard.  There are kludgey ways to do it in Litmus with just 5 to 10 minutes of coding.
> 
> -Glenn


Hi Zheng,

(AFFINITY)

CPU affinity in Litmus is pretty well tested, so I would be surprised if it were broken.  What behaviors are you observing that make you think that it is broken?  To rule out programmer error, please make sure you are setting affinity masks via Litmus’s helper APIs found in liblitmus/include/migration.h:

be_migrate_to_cpu()
be_migrate_to_partition()
be_migrate_to_cluster()

Please note that these functions must be called BEFORE a task enters real-time mode.  Observe that CPU affinity is used to assign tasks to partitions/clusters.

If you are using partitioned or clustered scheduling, then you want to use be_migrate_to_partition() and be_migrate_to_cluster(), respectively.  Note that be_migrate_to_partition() and be_migrate_to_cluster() APIs are release-master aware.  For instance, when release master is enabled and is set to CPU0, the 0th partition starts on CPU1.  When release master is disabled, the 0th partition starts on CPU0.  

You can use be_migrate_to_cpu() to pin the callee to a particular CPU if you want that sort of lower-level control.  This API is easier to use that Linux’s API if you need to pin to just one CPU (rather than a collection of CPUs).

(RELASE MASTER)

I believe that I was mistaken in my earlier email.  I had forgotten that release master was configurable (I had assumed that CPU0 was automatically set up as the release master).

You can set a release master CPU by echo’ing a CPU to /proc/litmus/release_master.
Example:
> sudo echo “0” > /proc/litmus/release_master

IMPORTANT: You must select a release master before you activate a Litmus scheduler plugin. That is, you can set a release master whenever the active plugin is “Linux”.

You can query for the release master CPU via liblitmus in your applications with the release_master() API, also found in liblitmus/include/migration.h.  The function returns “-1” if a release master CPU has not been selected (or is not supported by the kernel, i.e., support was not configured into the kernel when it was compiled).  Otherwise, it will return the CPU# of the release master.

Yes, support for release master is a kernel compile-time option (hence, my earlier reference to CONFIG_RELEASE_MASTER).  Once you boot into the Litmus kernel, you should see “release_master” in /proc/litmus.  If you don’t, Litmus wasn’t compiled correctly.

(ATTENTION EVERYONE)

We are __very__ pleased that others outside of UNC and MPI have taken an interest in Litmus and want to experiment with it.  This has always been a goal for us, and we will always help others whenever we can.  That said, lately we’ve been receiving a lot of emails on the mailing list that lack enough information for us to be helpful.  Working with Litmus can be challenging at first, especially if you have never done kernel development before.  I understand that frustration can lead you to quickly shoot off a short email to the Litmus mailing list.  However, in the future, please try to be more __thoughtful__ with your questions.  Be more descriptive.  We can’t help if you merely say “it doesn’t work.”  Ask yourself, “What sort of information would someone need in order to answer my question?"  What code appears to be broken?  What is your code?  Are you doing something different than the example applications in liblitmus?  Are there any error messages printed to the console log?  What evidence can you show that the system is functioning improperly (logs, traces, etc.)?  More often than not, when *I* go through these steps and actually gather the requisite information, I find the answer for myself.  And when I don’t, everyone has enough information to help out.

Best Regards,
Glenn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litmus-rt.org/pipermail/litmus-dev/attachments/20131214/206da732/attachment.html>