* [Xenomai-help] Scheduling questions... @ 2011-03-24 23:47 Eric Eric 2011-03-25 8:21 ` Philippe Gerum 2011-03-25 10:17 ` Gilles Chanteperdrix 0 siblings, 2 replies; 13+ messages in thread From: Eric Eric @ 2011-03-24 23:47 UTC (permalink / raw) To: xenomai Hello, I've been reading through some of the documentation and have a few questions regarding scheduling: - API docs say that rt_task_set_mode can allow a task to undergo round-robin scheduling. This seems to imply that we can have an environment of mixed round-robin and FIFO task scheduling. Is this correct? If so, what is the scheduling relationship between tasks running in FIFO and RR modes? - I am concerned about Linux starvation. For example, suppose a misbehaving RT task spins and burns CPU indefinitely (watchdog notwithstanding). I would still like to preempt this task and allow Linux to run for up to some maximum time (say up to 30mS every 200mS). So, if using RR scheduling, is there a way to use rt_task_slice to allocate time to Linux? Is there a Linux shadow thread that I can allocate time to? Thank you. - Eric ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-24 23:47 [Xenomai-help] Scheduling questions Eric Eric @ 2011-03-25 8:21 ` Philippe Gerum 2011-03-25 19:48 ` Eric Eric 2011-03-25 10:17 ` Gilles Chanteperdrix 1 sibling, 1 reply; 13+ messages in thread From: Philippe Gerum @ 2011-03-25 8:21 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > Hello, I've been reading through some of the documentation and have a > few questions regarding scheduling: > > - API docs say that rt_task_set_mode can allow a task to undergo > round-robin scheduling. This seems to imply that we can have an > environment of mixed round-robin and FIFO task scheduling. Is this > correct? If so, what is the scheduling relationship between tasks > running in FIFO and RR modes? RR are FIFO threads within the same priority group. > > - I am concerned about Linux starvation. For example, suppose a > misbehaving RT task spins and burns CPU indefinitely (watchdog > notwithstanding). I would still like to preempt this task and allow > Linux to run for up to some maximum time (say up to 30mS every 200mS). > So, if using RR scheduling, is there a way to use rt_task_slice to > allocate time to Linux? Is there a Linux shadow thread that I can > allocate time to? Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, usable with int pthread_setschedparam_ex(). > > Thank you. > > - Eric > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 8:21 ` Philippe Gerum @ 2011-03-25 19:48 ` Eric Eric 2011-03-25 19:59 ` Philippe Gerum 0 siblings, 1 reply; 13+ messages in thread From: Eric Eric @ 2011-03-25 19:48 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Roger on the RR/FIFO scheduling question. Regarding Linux starvation, it looks like pthread_setschedparam_ex can be used on a particular Linux thread to avoid starvation, however I'm more concerned about the Linux kernel itself. In the example below, I may want the kernel to have some time to service interrupts even if an RT task is behaving badly. How could I achieve this? Thanks again for the fast and helpful responses! - Eric On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: >> Hello, I've been reading through some of the documentation and have a >> few questions regarding scheduling: >> >> - API docs say that rt_task_set_mode can allow a task to undergo >> round-robin scheduling. This seems to imply that we can have an >> environment of mixed round-robin and FIFO task scheduling. Is this >> correct? If so, what is the scheduling relationship between tasks >> running in FIFO and RR modes? > > RR are FIFO threads within the same priority group. > >> >> - I am concerned about Linux starvation. For example, suppose a >> misbehaving RT task spins and burns CPU indefinitely (watchdog >> notwithstanding). I would still like to preempt this task and allow >> Linux to run for up to some maximum time (say up to 30mS every 200mS). >> So, if using RR scheduling, is there a way to use rt_task_slice to >> allocate time to Linux? Is there a Linux shadow thread that I can >> allocate time to? > > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > usable with int pthread_setschedparam_ex(). > >> >> Thank you. >> >> - Eric >> >> _______________________________________________ >> Xenomai-help mailing list >> Xenomai-help@domain.hid >> https://mail.gna.org/listinfo/xenomai-help > > -- > Philippe. > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 19:48 ` Eric Eric @ 2011-03-25 19:59 ` Philippe Gerum 2011-03-25 20:43 ` Eric Eric 0 siblings, 1 reply; 13+ messages in thread From: Philippe Gerum @ 2011-03-25 19:59 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: > Roger on the RR/FIFO scheduling question. Regarding Linux starvation, > it looks like pthread_setschedparam_ex can be used on a particular > Linux thread to avoid starvation, however I'm more concerned about the > Linux kernel itself. In the example below, I may want the kernel to > have some time to service interrupts even if an RT task is behaving > badly. How could I achieve this? As an extension, Xenomai interprets param.low_prio == -1 as "suspend the thread". So each time the thread exceed its runtime credit, the nucleus suspends it until it is replenished, instead of merely downgrading its priority. As a side-effect, Linux becomes runnable again (unless another -rt thread is requesting the CPU immediately, but you get the point). > > Thanks again for the fast and helpful responses! > > - Eric > > On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > >> Hello, I've been reading through some of the documentation and have a > >> few questions regarding scheduling: > >> > >> - API docs say that rt_task_set_mode can allow a task to undergo > >> round-robin scheduling. This seems to imply that we can have an > >> environment of mixed round-robin and FIFO task scheduling. Is this > >> correct? If so, what is the scheduling relationship between tasks > >> running in FIFO and RR modes? > > > > RR are FIFO threads within the same priority group. > > > >> > >> - I am concerned about Linux starvation. For example, suppose a > >> misbehaving RT task spins and burns CPU indefinitely (watchdog > >> notwithstanding). I would still like to preempt this task and allow > >> Linux to run for up to some maximum time (say up to 30mS every 200mS). > >> So, if using RR scheduling, is there a way to use rt_task_slice to > >> allocate time to Linux? Is there a Linux shadow thread that I can > >> allocate time to? > > > > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > > usable with int pthread_setschedparam_ex(). > > > >> > >> Thank you. > >> > >> - Eric > >> > >> _______________________________________________ > >> Xenomai-help mailing list > >> Xenomai-help@domain.hid > >> https://mail.gna.org/listinfo/xenomai-help > > > > -- > > Philippe. > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 19:59 ` Philippe Gerum @ 2011-03-25 20:43 ` Eric Eric 2011-03-25 20:52 ` Philippe Gerum 0 siblings, 1 reply; 13+ messages in thread From: Eric Eric @ 2011-03-25 20:43 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai What I'm really asking about is specifically the "unless" clause at the end of your response. Assume a high priority RT thread is doing something like while(1) { } and just spinning and eating CPU. I would like to force the Linux kernel to be scheduled for, say, up to 20mS every 200mS to give it the opportunity to service Linux interrupts even if the high-priority RT task is runnable (ie I want to periodically preempt the RT thread and allow the Linux kernel to run for a limited amount of time). It looks like SCHED_SPORADIC is a way to do this, I'm just not sure how to apply that to the kernel itself. Thanks, - Eric On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, >> it looks like pthread_setschedparam_ex can be used on a particular >> Linux thread to avoid starvation, however I'm more concerned about the >> Linux kernel itself. In the example below, I may want the kernel to >> have some time to service interrupts even if an RT task is behaving >> badly. How could I achieve this? > > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the > thread". So each time the thread exceed its runtime credit, the nucleus > suspends it until it is replenished, instead of merely downgrading its > priority. As a side-effect, Linux becomes runnable again (unless another > -rt thread is requesting the CPU immediately, but you get the point). > >> >> Thanks again for the fast and helpful responses! >> >> - Eric >> >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: >> >> Hello, I've been reading through some of the documentation and have a >> >> few questions regarding scheduling: >> >> >> >> - API docs say that rt_task_set_mode can allow a task to undergo >> >> round-robin scheduling. This seems to imply that we can have an >> >> environment of mixed round-robin and FIFO task scheduling. Is this >> >> correct? If so, what is the scheduling relationship between tasks >> >> running in FIFO and RR modes? >> > >> > RR are FIFO threads within the same priority group. >> > >> >> >> >> - I am concerned about Linux starvation. For example, suppose a >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog >> >> notwithstanding). I would still like to preempt this task and allow >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). >> >> So, if using RR scheduling, is there a way to use rt_task_slice to >> >> allocate time to Linux? Is there a Linux shadow thread that I can >> >> allocate time to? >> > >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, >> > usable with int pthread_setschedparam_ex(). >> > >> >> >> >> Thank you. >> >> >> >> - Eric >> >> >> >> _______________________________________________ >> >> Xenomai-help mailing list >> >> Xenomai-help@domain.hid >> >> https://mail.gna.org/listinfo/xenomai-help >> > >> > -- >> > Philippe. >> > >> > >> > > > -- > Philippe. > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 20:43 ` Eric Eric @ 2011-03-25 20:52 ` Philippe Gerum 2011-03-25 20:53 ` Philippe Gerum 2011-03-25 21:28 ` Eric Eric 0 siblings, 2 replies; 13+ messages in thread From: Philippe Gerum @ 2011-03-25 20:52 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: > What I'm really asking about is specifically the "unless" clause at > the end of your response. Assume a high priority RT thread is doing > something like while(1) { } and just spinning and eating CPU. I would > like to force the Linux kernel to be scheduled for, say, up to 20mS > every 200mS to give it the opportunity to service Linux interrupts > even if the high-priority RT task is runnable (ie I want to > periodically preempt the RT thread and allow the Linux kernel to run > for a limited amount of time). It looks like SCHED_SPORADIC is a way > to do this, I'm just not sure how to apply that to the kernel itself. Scheduling all threads your create within the SCHED_SPORADIC class, with specifying a background priority set to -1 for all of them would do the job. > > Thanks, > > - Eric > > On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: > > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: > >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, > >> it looks like pthread_setschedparam_ex can be used on a particular > >> Linux thread to avoid starvation, however I'm more concerned about the > >> Linux kernel itself. In the example below, I may want the kernel to > >> have some time to service interrupts even if an RT task is behaving > >> badly. How could I achieve this? > > > > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the > > thread". So each time the thread exceed its runtime credit, the nucleus > > suspends it until it is replenished, instead of merely downgrading its > > priority. As a side-effect, Linux becomes runnable again (unless another > > -rt thread is requesting the CPU immediately, but you get the point). > > > >> > >> Thanks again for the fast and helpful responses! > >> > >> - Eric > >> > >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > >> >> Hello, I've been reading through some of the documentation and have a > >> >> few questions regarding scheduling: > >> >> > >> >> - API docs say that rt_task_set_mode can allow a task to undergo > >> >> round-robin scheduling. This seems to imply that we can have an > >> >> environment of mixed round-robin and FIFO task scheduling. Is this > >> >> correct? If so, what is the scheduling relationship between tasks > >> >> running in FIFO and RR modes? > >> > > >> > RR are FIFO threads within the same priority group. > >> > > >> >> > >> >> - I am concerned about Linux starvation. For example, suppose a > >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog > >> >> notwithstanding). I would still like to preempt this task and allow > >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). > >> >> So, if using RR scheduling, is there a way to use rt_task_slice to > >> >> allocate time to Linux? Is there a Linux shadow thread that I can > >> >> allocate time to? > >> > > >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > >> > usable with int pthread_setschedparam_ex(). > >> > > >> >> > >> >> Thank you. > >> >> > >> >> - Eric > >> >> > >> >> _______________________________________________ > >> >> Xenomai-help mailing list > >> >> Xenomai-help@domain.hid > >> >> https://mail.gna.org/listinfo/xenomai-help > >> > > >> > -- > >> > Philippe. > >> > > >> > > >> > > > > > -- > > Philippe. > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 20:52 ` Philippe Gerum @ 2011-03-25 20:53 ` Philippe Gerum 2011-03-25 21:28 ` Eric Eric 1 sibling, 0 replies; 13+ messages in thread From: Philippe Gerum @ 2011-03-25 20:53 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Fri, 2011-03-25 at 21:52 +0100, Philippe Gerum wrote: > On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: > > What I'm really asking about is specifically the "unless" clause at > > the end of your response. Assume a high priority RT thread is doing > > something like while(1) { } and just spinning and eating CPU. I would > > like to force the Linux kernel to be scheduled for, say, up to 20mS > > every 200mS to give it the opportunity to service Linux interrupts > > even if the high-priority RT task is runnable (ie I want to > > periodically preempt the RT thread and allow the Linux kernel to run > > for a limited amount of time). It looks like SCHED_SPORADIC is a way > > to do this, I'm just not sure how to apply that to the kernel itself. > > Scheduling all threads your create within the SCHED_SPORADIC class, with > specifying a background priority set to -1 for all of them would do the > job. SPORADIC threads are FIFO threads with a time budget. > > > > > Thanks, > > > > - Eric > > > > On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: > > > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: > > >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, > > >> it looks like pthread_setschedparam_ex can be used on a particular > > >> Linux thread to avoid starvation, however I'm more concerned about the > > >> Linux kernel itself. In the example below, I may want the kernel to > > >> have some time to service interrupts even if an RT task is behaving > > >> badly. How could I achieve this? > > > > > > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the > > > thread". So each time the thread exceed its runtime credit, the nucleus > > > suspends it until it is replenished, instead of merely downgrading its > > > priority. As a side-effect, Linux becomes runnable again (unless another > > > -rt thread is requesting the CPU immediately, but you get the point). > > > > > >> > > >> Thanks again for the fast and helpful responses! > > >> > > >> - Eric > > >> > > >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > > >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > > >> >> Hello, I've been reading through some of the documentation and have a > > >> >> few questions regarding scheduling: > > >> >> > > >> >> - API docs say that rt_task_set_mode can allow a task to undergo > > >> >> round-robin scheduling. This seems to imply that we can have an > > >> >> environment of mixed round-robin and FIFO task scheduling. Is this > > >> >> correct? If so, what is the scheduling relationship between tasks > > >> >> running in FIFO and RR modes? > > >> > > > >> > RR are FIFO threads within the same priority group. > > >> > > > >> >> > > >> >> - I am concerned about Linux starvation. For example, suppose a > > >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog > > >> >> notwithstanding). I would still like to preempt this task and allow > > >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). > > >> >> So, if using RR scheduling, is there a way to use rt_task_slice to > > >> >> allocate time to Linux? Is there a Linux shadow thread that I can > > >> >> allocate time to? > > >> > > > >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > > >> > usable with int pthread_setschedparam_ex(). > > >> > > > >> >> > > >> >> Thank you. > > >> >> > > >> >> - Eric > > >> >> > > >> >> _______________________________________________ > > >> >> Xenomai-help mailing list > > >> >> Xenomai-help@domain.hid > > >> >> https://mail.gna.org/listinfo/xenomai-help > > >> > > > >> > -- > > >> > Philippe. > > >> > > > >> > > > >> > > > > > > > -- > > > Philippe. > > > > > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 20:52 ` Philippe Gerum 2011-03-25 20:53 ` Philippe Gerum @ 2011-03-25 21:28 ` Eric Eric 2011-03-30 4:54 ` Philippe Gerum 1 sibling, 1 reply; 13+ messages in thread From: Eric Eric @ 2011-03-25 21:28 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Great, I think that clears it up. Let me just make sure I understand. First, setting background priority (I assume you mean sched_ss_low_priority in pthreads) to -1 will cause a thread to be unrunnable after exhausting its credit. Next, if I had say 4 real time threads, and set them all to get 20mS credit every 100mS, that would leave 20mS during which Linux would be come runnable due to the low_priority being -1 for all RT threads, correct? So I think I understand how this would work using the POSIX skin, but I'm planning to do all my work with the native API. I'm a bit concerned because it appears things like xnsched_sporadic members are only manipulated in nucleus and POSIX, not native. Can I achieve the goal of ensuring the Linux kernel gets time to run using only the native API? Thanks again. - Eric On Fri, Mar 25, 2011 at 4:52 PM, Philippe Gerum <rpm@xenomai.org> wrote: > On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: >> What I'm really asking about is specifically the "unless" clause at >> the end of your response. Assume a high priority RT thread is doing >> something like while(1) { } and just spinning and eating CPU. I would >> like to force the Linux kernel to be scheduled for, say, up to 20mS >> every 200mS to give it the opportunity to service Linux interrupts >> even if the high-priority RT task is runnable (ie I want to >> periodically preempt the RT thread and allow the Linux kernel to run >> for a limited amount of time). It looks like SCHED_SPORADIC is a way >> to do this, I'm just not sure how to apply that to the kernel itself. > > Scheduling all threads your create within the SCHED_SPORADIC class, with > specifying a background priority set to -1 for all of them would do the > job. > >> >> Thanks, >> >> - Eric >> >> On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: >> > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: >> >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, >> >> it looks like pthread_setschedparam_ex can be used on a particular >> >> Linux thread to avoid starvation, however I'm more concerned about the >> >> Linux kernel itself. In the example below, I may want the kernel to >> >> have some time to service interrupts even if an RT task is behaving >> >> badly. How could I achieve this? >> > >> > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the >> > thread". So each time the thread exceed its runtime credit, the nucleus >> > suspends it until it is replenished, instead of merely downgrading its >> > priority. As a side-effect, Linux becomes runnable again (unless another >> > -rt thread is requesting the CPU immediately, but you get the point). >> > >> >> >> >> Thanks again for the fast and helpful responses! >> >> >> >> - Eric >> >> >> >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: >> >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: >> >> >> Hello, I've been reading through some of the documentation and have a >> >> >> few questions regarding scheduling: >> >> >> >> >> >> - API docs say that rt_task_set_mode can allow a task to undergo >> >> >> round-robin scheduling. This seems to imply that we can have an >> >> >> environment of mixed round-robin and FIFO task scheduling. Is this >> >> >> correct? If so, what is the scheduling relationship between tasks >> >> >> running in FIFO and RR modes? >> >> > >> >> > RR are FIFO threads within the same priority group. >> >> > >> >> >> >> >> >> - I am concerned about Linux starvation. For example, suppose a >> >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog >> >> >> notwithstanding). I would still like to preempt this task and allow >> >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). >> >> >> So, if using RR scheduling, is there a way to use rt_task_slice to >> >> >> allocate time to Linux? Is there a Linux shadow thread that I can >> >> >> allocate time to? >> >> > >> >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, >> >> > usable with int pthread_setschedparam_ex(). >> >> > >> >> >> >> >> >> Thank you. >> >> >> >> >> >> - Eric >> >> >> >> >> >> _______________________________________________ >> >> >> Xenomai-help mailing list >> >> >> Xenomai-help@domain.hid >> >> >> https://mail.gna.org/listinfo/xenomai-help >> >> > >> >> > -- >> >> > Philippe. >> >> > >> >> > >> >> > >> > >> > -- >> > Philippe. >> > >> > >> > > > -- > Philippe. > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-25 21:28 ` Eric Eric @ 2011-03-30 4:54 ` Philippe Gerum 2011-03-30 18:37 ` Eric Eric 0 siblings, 1 reply; 13+ messages in thread From: Philippe Gerum @ 2011-03-30 4:54 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Fri, 2011-03-25 at 17:28 -0400, Eric Eric wrote: > Great, I think that clears it up. Let me just make sure I understand. > First, setting background priority (I assume you mean > sched_ss_low_priority in pthreads) to -1 will cause a thread to be > unrunnable after exhausting its credit. Next, if I had say 4 real > time threads, and set them all to get 20mS credit every 100mS, that > would leave 20mS during which Linux would be come runnable due to the > low_priority being -1 for all RT threads, correct? Correct. An even more fine grained control over the scheduling slots could be achieved using the temporal partitioning scheduling class (TP). This one precisely defines usable time windows for threads on each CPU, typical of IMA systems. But there is no userland programming interface for this one, it is currently aimed at supporting skins which would then export the TP feature via their own API to user-space. There is no such skin in the baseline yet. > > So I think I understand how this would work using the POSIX skin, but > I'm planning to do all my work with the native API. I'm a bit > concerned because it appears things like xnsched_sporadic members are > only manipulated in nucleus and POSIX, not native. Can I achieve the > goal of ensuring the Linux kernel gets time to run using only the > native API? > Nope. This scheduler interface is only available with the POSIX skin, and there is no plan to extend the native interface for this. > Thanks again. > > - Eric > > On Fri, Mar 25, 2011 at 4:52 PM, Philippe Gerum <rpm@xenomai.org> wrote: > > On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: > >> What I'm really asking about is specifically the "unless" clause at > >> the end of your response. Assume a high priority RT thread is doing > >> something like while(1) { } and just spinning and eating CPU. I would > >> like to force the Linux kernel to be scheduled for, say, up to 20mS > >> every 200mS to give it the opportunity to service Linux interrupts > >> even if the high-priority RT task is runnable (ie I want to > >> periodically preempt the RT thread and allow the Linux kernel to run > >> for a limited amount of time). It looks like SCHED_SPORADIC is a way > >> to do this, I'm just not sure how to apply that to the kernel itself. > > > > Scheduling all threads your create within the SCHED_SPORADIC class, with > > specifying a background priority set to -1 for all of them would do the > > job. > > > >> > >> Thanks, > >> > >> - Eric > >> > >> On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: > >> > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: > >> >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, > >> >> it looks like pthread_setschedparam_ex can be used on a particular > >> >> Linux thread to avoid starvation, however I'm more concerned about the > >> >> Linux kernel itself. In the example below, I may want the kernel to > >> >> have some time to service interrupts even if an RT task is behaving > >> >> badly. How could I achieve this? > >> > > >> > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the > >> > thread". So each time the thread exceed its runtime credit, the nucleus > >> > suspends it until it is replenished, instead of merely downgrading its > >> > priority. As a side-effect, Linux becomes runnable again (unless another > >> > -rt thread is requesting the CPU immediately, but you get the point). > >> > > >> >> > >> >> Thanks again for the fast and helpful responses! > >> >> > >> >> - Eric > >> >> > >> >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > >> >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > >> >> >> Hello, I've been reading through some of the documentation and have a > >> >> >> few questions regarding scheduling: > >> >> >> > >> >> >> - API docs say that rt_task_set_mode can allow a task to undergo > >> >> >> round-robin scheduling. This seems to imply that we can have an > >> >> >> environment of mixed round-robin and FIFO task scheduling. Is this > >> >> >> correct? If so, what is the scheduling relationship between tasks > >> >> >> running in FIFO and RR modes? > >> >> > > >> >> > RR are FIFO threads within the same priority group. > >> >> > > >> >> >> > >> >> >> - I am concerned about Linux starvation. For example, suppose a > >> >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog > >> >> >> notwithstanding). I would still like to preempt this task and allow > >> >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). > >> >> >> So, if using RR scheduling, is there a way to use rt_task_slice to > >> >> >> allocate time to Linux? Is there a Linux shadow thread that I can > >> >> >> allocate time to? > >> >> > > >> >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > >> >> > usable with int pthread_setschedparam_ex(). > >> >> > > >> >> >> > >> >> >> Thank you. > >> >> >> > >> >> >> - Eric > >> >> >> > >> >> >> _______________________________________________ > >> >> >> Xenomai-help mailing list > >> >> >> Xenomai-help@domain.hid > >> >> >> https://mail.gna.org/listinfo/xenomai-help > >> >> > > >> >> > -- > >> >> > Philippe. > >> >> > > >> >> > > >> >> > > >> > > >> > -- > >> > Philippe. > >> > > >> > > >> > > > > > -- > > Philippe. > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-30 4:54 ` Philippe Gerum @ 2011-03-30 18:37 ` Eric Eric 2011-03-30 21:43 ` Gilles Chanteperdrix 2011-03-31 8:54 ` Philippe Gerum 0 siblings, 2 replies; 13+ messages in thread From: Eric Eric @ 2011-03-30 18:37 UTC (permalink / raw) To: Philippe Gerum; +Cc: xenomai Thanks Philippe. I was thinking of avoiding POSIX only because some of my colleagues have noticed severe performance hits using non-native skins in commercial RTOSs, particularly Integrity. Would you expect POSIX performance to be roughly the same as native? TP is interesting, and may work for my applications since we are likely to do much of our real-time work in-kernel to get the absolute minimum latency possible. On a related note, I noticed on page 14 of http://retis.sssup.it/~lipari/courses/str09/12.xeno-handout.pdf that when Xenomai is in secondary mode, all Linux interrupts are stalled. This would seem to imply that doing something like select in a Xenomai user-task would be problematic, as we would have wait until Linux goes into background mode to unstall Linux interrupts. Is there any way around this? The slide suggests that this behavior is "to reduce latency" although I suspect there may be other motivations. Thank you again for helping to answer my questions. It has been extremely helpful as I continue to evaluate Xenomai. - Eric On Wed, Mar 30, 2011 at 12:54 AM, Philippe Gerum <rpm@xenomai.org> wrote: > On Fri, 2011-03-25 at 17:28 -0400, Eric Eric wrote: >> Great, I think that clears it up. Let me just make sure I understand. >> First, setting background priority (I assume you mean >> sched_ss_low_priority in pthreads) to -1 will cause a thread to be >> unrunnable after exhausting its credit. Next, if I had say 4 real >> time threads, and set them all to get 20mS credit every 100mS, that >> would leave 20mS during which Linux would be come runnable due to the >> low_priority being -1 for all RT threads, correct? > > Correct. An even more fine grained control over the scheduling slots > could be achieved using the temporal partitioning scheduling class (TP). > This one precisely defines usable time windows for threads on each CPU, > typical of IMA systems. But there is no userland programming interface > for this one, it is currently aimed at supporting skins which would then > export the TP feature via their own API to user-space. There is no such > skin in the baseline yet. > >> >> So I think I understand how this would work using the POSIX skin, but >> I'm planning to do all my work with the native API. I'm a bit >> concerned because it appears things like xnsched_sporadic members are >> only manipulated in nucleus and POSIX, not native. Can I achieve the >> goal of ensuring the Linux kernel gets time to run using only the >> native API? >> > > Nope. This scheduler interface is only available with the POSIX skin, > and there is no plan to extend the native interface for this. > >> Thanks again. >> >> - Eric >> >> On Fri, Mar 25, 2011 at 4:52 PM, Philippe Gerum <rpm@xenomai.org> wrote: >> > On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: >> >> What I'm really asking about is specifically the "unless" clause at >> >> the end of your response. Assume a high priority RT thread is doing >> >> something like while(1) { } and just spinning and eating CPU. I would >> >> like to force the Linux kernel to be scheduled for, say, up to 20mS >> >> every 200mS to give it the opportunity to service Linux interrupts >> >> even if the high-priority RT task is runnable (ie I want to >> >> periodically preempt the RT thread and allow the Linux kernel to run >> >> for a limited amount of time). It looks like SCHED_SPORADIC is a way >> >> to do this, I'm just not sure how to apply that to the kernel itself. >> > >> > Scheduling all threads your create within the SCHED_SPORADIC class, with >> > specifying a background priority set to -1 for all of them would do the >> > job. >> > >> >> >> >> Thanks, >> >> >> >> - Eric >> >> >> >> On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: >> >> > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: >> >> >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, >> >> >> it looks like pthread_setschedparam_ex can be used on a particular >> >> >> Linux thread to avoid starvation, however I'm more concerned about the >> >> >> Linux kernel itself. In the example below, I may want the kernel to >> >> >> have some time to service interrupts even if an RT task is behaving >> >> >> badly. How could I achieve this? >> >> > >> >> > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the >> >> > thread". So each time the thread exceed its runtime credit, the nucleus >> >> > suspends it until it is replenished, instead of merely downgrading its >> >> > priority. As a side-effect, Linux becomes runnable again (unless another >> >> > -rt thread is requesting the CPU immediately, but you get the point). >> >> > >> >> >> >> >> >> Thanks again for the fast and helpful responses! >> >> >> >> >> >> - Eric >> >> >> >> >> >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: >> >> >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: >> >> >> >> Hello, I've been reading through some of the documentation and have a >> >> >> >> few questions regarding scheduling: >> >> >> >> >> >> >> >> - API docs say that rt_task_set_mode can allow a task to undergo >> >> >> >> round-robin scheduling. This seems to imply that we can have an >> >> >> >> environment of mixed round-robin and FIFO task scheduling. Is this >> >> >> >> correct? If so, what is the scheduling relationship between tasks >> >> >> >> running in FIFO and RR modes? >> >> >> > >> >> >> > RR are FIFO threads within the same priority group. >> >> >> > >> >> >> >> >> >> >> >> - I am concerned about Linux starvation. For example, suppose a >> >> >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog >> >> >> >> notwithstanding). I would still like to preempt this task and allow >> >> >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). >> >> >> >> So, if using RR scheduling, is there a way to use rt_task_slice to >> >> >> >> allocate time to Linux? Is there a Linux shadow thread that I can >> >> >> >> allocate time to? >> >> >> > >> >> >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, >> >> >> > usable with int pthread_setschedparam_ex(). >> >> >> > >> >> >> >> >> >> >> >> Thank you. >> >> >> >> >> >> >> >> - Eric >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> Xenomai-help mailing list >> >> >> >> Xenomai-help@domain.hid >> >> >> >> https://mail.gna.org/listinfo/xenomai-help >> >> >> > >> >> >> > -- >> >> >> > Philippe. >> >> >> > >> >> >> > >> >> >> > >> >> > >> >> > -- >> >> > Philippe. >> >> > >> >> > >> >> > >> > >> > -- >> > Philippe. >> > >> > >> > > > -- > Philippe. > > > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-30 18:37 ` Eric Eric @ 2011-03-30 21:43 ` Gilles Chanteperdrix 2011-03-31 8:54 ` Philippe Gerum 1 sibling, 0 replies; 13+ messages in thread From: Gilles Chanteperdrix @ 2011-03-30 21:43 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai Eric Eric wrote: > Thanks Philippe. I was thinking of avoiding POSIX only because some > of my colleagues have noticed severe performance hits using non-native > skins in commercial RTOSs, particularly Integrity. Would you expect > POSIX performance to be roughly the same as native? Hi Eric, posix and native are both skins implemented using the same internal services, so, their performances should be comparable. If you find some posix service much slower than its native counterpart, we would consider it a bug. > TP is interesting, and may work for my applications since we are likely to > do much of our real-time work in-kernel to get the absolute minimum > latency possible. On what hardware? On a typical x86 machine, the user-space performances are sufficient for a large majority of applications. Besides, there are other points to consider than performance in order to choose between kernel-space and user-space: - kernel-space code is harder to debug, this results in longer time to complete your project; - kernel-space code is covered by the GPL license; - imitating what you do with the Linux kernel, you can split the code between application and driver, the driver going to kernel-space and being implemented on top of the RTDM skin; - Xenomai kernel-space APIs will be discontinued in Xenomai 3.x branch (except, obviously, the RTDM skin). I would go the other way: first try user-space, if performances are not sufficient, they try and find other ways, maybe changing hardware for instance, move time critical parts in an RTDM driver, and move the application to kernel-space only as the last resort. > > On a related note, I noticed on page 14 of > http://retis.sssup.it/~lipari/courses/str09/12.xeno-handout.pdf that > when Xenomai is in secondary mode, all Linux interrupts are stalled. > This would seem to imply that doing something like select in a Xenomai > user-task would be problematic, as we would have wait until Linux goes > into background mode to unstall Linux interrupts. Is there any way > around this? The slide suggests that this behavior is "to reduce > latency" although I suspect there may be other motivations. The irq shield is not available in recent versions of Xenomai. But when it was still there, obvious cases such as a thread suspending after entering secondary mode were handled by disabling the shield in that case: the shield was only enabled when a Xenomai thread was running in secondary mode, not when it was suspended. Regards. -- Gilles. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-30 18:37 ` Eric Eric 2011-03-30 21:43 ` Gilles Chanteperdrix @ 2011-03-31 8:54 ` Philippe Gerum 1 sibling, 0 replies; 13+ messages in thread From: Philippe Gerum @ 2011-03-31 8:54 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai On Wed, 2011-03-30 at 14:37 -0400, Eric Eric wrote: > Thanks Philippe. I was thinking of avoiding POSIX only because some > of my colleagues have noticed severe performance hits using non-native > skins in commercial RTOSs, particularly Integrity. Would you expect > POSIX performance to be roughly the same as native? Unlike most RTOSs, Xenomai provides a set of basic building blocks, all APIs are built over. Think of it as a LEGO box for people with way too much free time, toying with real-time API design and implementation. This means that posix, native, vxworks, psos, vrtx ... whatever API/emulator built over Xenomai is actually based on the same set of building blocks, we call this set the "nucleus". So the only way for a Xenomai API to be significantly "slower" than its neighbor on the same stack is to have been badly implemented, not because several APIs were piled up to build it, introducing overhead. I suspect this is the issue you had in mind about some POSIX implementations. The other reason for not deriving our POSIX implementation from any so-called "native" API was standard conformance: we just don't know how to match all POSIX semantics on top of traditional RTOS semantics, given they are often at odds in significant aspects of their respective standard. > TP is > interesting, and may work for my applications since we are likely to > do much of our real-time work in-kernel to get the absolute minimum > latency possible. > > On a related note, I noticed on page 14 of > http://retis.sssup.it/~lipari/courses/str09/12.xeno-handout.pdf that > when Xenomai is in secondary mode, all Linux interrupts are stalled. > This would seem to imply that doing something like select in a Xenomai > user-task would be problematic, as we would have wait until Linux goes > into background mode to unstall Linux interrupts. Is there any way > around this? The slide suggests that this behavior is "to reduce > latency" although I suspect there may be other motivations. > > Thank you again for helping to answer my questions. It has been > extremely helpful as I continue to evaluate Xenomai. > > - Eric > > On Wed, Mar 30, 2011 at 12:54 AM, Philippe Gerum <rpm@xenomai.org> wrote: > > On Fri, 2011-03-25 at 17:28 -0400, Eric Eric wrote: > >> Great, I think that clears it up. Let me just make sure I understand. > >> First, setting background priority (I assume you mean > >> sched_ss_low_priority in pthreads) to -1 will cause a thread to be > >> unrunnable after exhausting its credit. Next, if I had say 4 real > >> time threads, and set them all to get 20mS credit every 100mS, that > >> would leave 20mS during which Linux would be come runnable due to the > >> low_priority being -1 for all RT threads, correct? > > > > Correct. An even more fine grained control over the scheduling slots > > could be achieved using the temporal partitioning scheduling class (TP). > > This one precisely defines usable time windows for threads on each CPU, > > typical of IMA systems. But there is no userland programming interface > > for this one, it is currently aimed at supporting skins which would then > > export the TP feature via their own API to user-space. There is no such > > skin in the baseline yet. > > > >> > >> So I think I understand how this would work using the POSIX skin, but > >> I'm planning to do all my work with the native API. I'm a bit > >> concerned because it appears things like xnsched_sporadic members are > >> only manipulated in nucleus and POSIX, not native. Can I achieve the > >> goal of ensuring the Linux kernel gets time to run using only the > >> native API? > >> > > > > Nope. This scheduler interface is only available with the POSIX skin, > > and there is no plan to extend the native interface for this. > > > >> Thanks again. > >> > >> - Eric > >> > >> On Fri, Mar 25, 2011 at 4:52 PM, Philippe Gerum <rpm@xenomai.org> wrote: > >> > On Fri, 2011-03-25 at 16:43 -0400, Eric Eric wrote: > >> >> What I'm really asking about is specifically the "unless" clause at > >> >> the end of your response. Assume a high priority RT thread is doing > >> >> something like while(1) { } and just spinning and eating CPU. I would > >> >> like to force the Linux kernel to be scheduled for, say, up to 20mS > >> >> every 200mS to give it the opportunity to service Linux interrupts > >> >> even if the high-priority RT task is runnable (ie I want to > >> >> periodically preempt the RT thread and allow the Linux kernel to run > >> >> for a limited amount of time). It looks like SCHED_SPORADIC is a way > >> >> to do this, I'm just not sure how to apply that to the kernel itself. > >> > > >> > Scheduling all threads your create within the SCHED_SPORADIC class, with > >> > specifying a background priority set to -1 for all of them would do the > >> > job. > >> > > >> >> > >> >> Thanks, > >> >> > >> >> - Eric > >> >> > >> >> On Fri, Mar 25, 2011 at 3:59 PM, Philippe Gerum <rpm@xenomai.org> wrote: > >> >> > On Fri, 2011-03-25 at 15:48 -0400, Eric Eric wrote: > >> >> >> Roger on the RR/FIFO scheduling question. Regarding Linux starvation, > >> >> >> it looks like pthread_setschedparam_ex can be used on a particular > >> >> >> Linux thread to avoid starvation, however I'm more concerned about the > >> >> >> Linux kernel itself. In the example below, I may want the kernel to > >> >> >> have some time to service interrupts even if an RT task is behaving > >> >> >> badly. How could I achieve this? > >> >> > > >> >> > As an extension, Xenomai interprets param.low_prio == -1 as "suspend the > >> >> > thread". So each time the thread exceed its runtime credit, the nucleus > >> >> > suspends it until it is replenished, instead of merely downgrading its > >> >> > priority. As a side-effect, Linux becomes runnable again (unless another > >> >> > -rt thread is requesting the CPU immediately, but you get the point). > >> >> > > >> >> >> > >> >> >> Thanks again for the fast and helpful responses! > >> >> >> > >> >> >> - Eric > >> >> >> > >> >> >> On Fri, Mar 25, 2011 at 4:21 AM, Philippe Gerum <rpm@xenomai.org> wrote: > >> >> >> > On Thu, 2011-03-24 at 19:47 -0400, Eric Eric wrote: > >> >> >> >> Hello, I've been reading through some of the documentation and have a > >> >> >> >> few questions regarding scheduling: > >> >> >> >> > >> >> >> >> - API docs say that rt_task_set_mode can allow a task to undergo > >> >> >> >> round-robin scheduling. This seems to imply that we can have an > >> >> >> >> environment of mixed round-robin and FIFO task scheduling. Is this > >> >> >> >> correct? If so, what is the scheduling relationship between tasks > >> >> >> >> running in FIFO and RR modes? > >> >> >> > > >> >> >> > RR are FIFO threads within the same priority group. > >> >> >> > > >> >> >> >> > >> >> >> >> - I am concerned about Linux starvation. For example, suppose a > >> >> >> >> misbehaving RT task spins and burns CPU indefinitely (watchdog > >> >> >> >> notwithstanding). I would still like to preempt this task and allow > >> >> >> >> Linux to run for up to some maximum time (say up to 30mS every 200mS). > >> >> >> >> So, if using RR scheduling, is there a way to use rt_task_slice to > >> >> >> >> allocate time to Linux? Is there a Linux shadow thread that I can > >> >> >> >> allocate time to? > >> >> >> > > >> >> >> > Xenomai implements sporadic server scheduling. See SCHED_SPORADIC, > >> >> >> > usable with int pthread_setschedparam_ex(). > >> >> >> > > >> >> >> >> > >> >> >> >> Thank you. > >> >> >> >> > >> >> >> >> - Eric > >> >> >> >> > >> >> >> >> _______________________________________________ > >> >> >> >> Xenomai-help mailing list > >> >> >> >> Xenomai-help@domain.hid > >> >> >> >> https://mail.gna.org/listinfo/xenomai-help > >> >> >> > > >> >> >> > -- > >> >> >> > Philippe. > >> >> >> > > >> >> >> > > >> >> >> > > >> >> > > >> >> > -- > >> >> > Philippe. > >> >> > > >> >> > > >> >> > > >> > > >> > -- > >> > Philippe. > >> > > >> > > >> > > > > > -- > > Philippe. > > > > > > -- Philippe. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Xenomai-help] Scheduling questions... 2011-03-24 23:47 [Xenomai-help] Scheduling questions Eric Eric 2011-03-25 8:21 ` Philippe Gerum @ 2011-03-25 10:17 ` Gilles Chanteperdrix 1 sibling, 0 replies; 13+ messages in thread From: Gilles Chanteperdrix @ 2011-03-25 10:17 UTC (permalink / raw) To: Eric Eric; +Cc: xenomai Eric Eric wrote: > Hello, I've been reading through some of the documentation and have a > few questions regarding scheduling: > > - API docs say that rt_task_set_mode can allow a task to undergo > round-robin scheduling. This seems to imply that we can have an > environment of mixed round-robin and FIFO task scheduling. Is this > correct? If so, what is the scheduling relationship between tasks > running in FIFO and RR modes? > > - I am concerned about Linux starvation. For example, suppose a > misbehaving RT task spins and burns CPU indefinitely (watchdog > notwithstanding). I would still like to preempt this task and allow > Linux to run for up to some maximum time (say up to 30mS every 200mS). > So, if using RR scheduling, is there a way to use rt_task_slice to > allocate time to Linux? Is there a Linux shadow thread that I can > allocate time to? It looks like you misunderstand round-robin: round-robin only occurs between tasks running at the same priority. That is what makes it compatible with FIFO scheduling. And that is the way RTOSes have always been doing this, and it is even in the posix specification with the SCHED_RR policy and the sched_yield() service. -- Gilles. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2011-03-31 8:54 UTC | newest] Thread overview: 13+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-24 23:47 [Xenomai-help] Scheduling questions Eric Eric 2011-03-25 8:21 ` Philippe Gerum 2011-03-25 19:48 ` Eric Eric 2011-03-25 19:59 ` Philippe Gerum 2011-03-25 20:43 ` Eric Eric 2011-03-25 20:52 ` Philippe Gerum 2011-03-25 20:53 ` Philippe Gerum 2011-03-25 21:28 ` Eric Eric 2011-03-30 4:54 ` Philippe Gerum 2011-03-30 18:37 ` Eric Eric 2011-03-30 21:43 ` Gilles Chanteperdrix 2011-03-31 8:54 ` Philippe Gerum 2011-03-25 10:17 ` Gilles Chanteperdrix
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.