Thanks Philippe, Gilles, Looking forward to this feature!
On Mon, Oct 4, 2010 at 1:02 PM, Philippe Gerum <[email protected]> wrote: > On Thu, 2010-09-30 at 14:52 +0200, Henri Roosen wrote: >> On Fri, Apr 23, 2010 at 12:54 PM, Philippe Gerum <[email protected]> wrote: >> > On Tue, 2010-04-20 at 10:12 -0400, Andreas Glatz wrote: >> >> > > > >> For the time being, you can work around this by issuing a Linux >> >> > > > >> syscall >> >> > > > >> before entering long processing loops - unless your task doesn't >> >> > > > >> do this >> >> > > > >> anyway, e.g. to perform some Linux I/O. >> >> > > > >> >> >> > > > > >> >> > > > > I think that's need. Currently the statistics task takes a mutex >> >> > > > > and waits on a message queue for messages. That's the only time >> >> > > > > it should potentially run in primary mode. After it returns the >> >> > > > > Mutex it should continue running with a policy similar to >> >> > > > > SCHED_IDLE to give other tasks a chance to run. I see how >> >> > > > > switching back to secondary mode could be achieved by issuing a >> >> > > > > Linux syscall. Is there another way which doesn't involve >> >> > > > > changing the source code of our application? (The proper way?) >> >> > > > >> >> > > > The proper way would be to not having to change the application >> >> > > > code. >> >> > > > But this workaround (Linux syscall or *_set_mode()) is required >> >> > > > until we >> >> > > > improve the nucleus. >> >> > > >> >> > > I generated a patch against 2.4.10.1 to get this behaviour (see >> >> > > further down). Instead of having >> >> > > to review and insert a Linux syscall or *_set_mode() in the >> >> > > application code I just call >> >> > > rt_task_set_mode(0, T_IDLE, NULL) at the beginning of the task body >> >> > > of the task which >> >> > > should mostly run in secondary mode under SCHED_IDLE (see example >> >> > > further down). The task >> >> > > marked with T_IDLE will switch to primary mode at every Xenomai >> >> > > skincall and immediately >> >> > > switch back to secondary mode once the Xenomai skincall is done. >> >> > > >> >> > > We identified just one case where this task has to stay in primary >> >> > > mode. This is between >> >> > > rt_mutex_aquire() and rt_mutex_release() since it may undergo a >> >> > > priority inversion boost. >> >> > > If the task stayed in secondary mode during that time it either would >> >> > > potentally delay the >> >> > > execution of a high priority task or would kill the system. >> >> > > >> >> > > The patch seems to work for us. Our statistics task which blocked the >> >> > > system for a long >> >> > > time (and made the UI running under Linux unresponsive) is running >> >> > > with T_IDLE. If Linux is >> >> > > heavily loaded now the statistics will get out of sync but the UI >> >> > > will still be responsive. >> >> > > >> >> > >> >> > The logic of this patch looks ok for the native skin, given that 2.4.x >> >> > does not provide a centralized implementation for dealing with exclusive >> >> > resources, like 2.5.x with xnsynch_acquire/release, and always emits a >> >> > syscall to manage those resources. >> >> > >> >> > This said, you could spare the T_IDLE tag by assuming that any non-RT >> >> > shadow thread has to switch back to secondary mode after a syscall, >> >> > unless the owned resource count is non-zero. This is where we are >> >> > heading to in 2.5.x, since the preferred mode of operation for such >> >> > thread has to be fundamentally "relaxed" (otherwise, one would have >> >> > created a RT thread, right). >> >> > >> >> > I'm also unsure you should force SCHED_IDLE, instead of picking >> >> > SCHED_OTHER for a more general approach to this issue. You can't assume >> >> > that userland does want to be reniced that way, at least not from the >> >> > nucleus. But I guess this fits your problem though. >> >> > >> >> > To sum up, since we can't really provide a true SCHED_IDLE policy on >> >> > linux (i.e. not a nice-level hack), and implementing a sched class in >> >> > Xenomai having a lower priority than the existing xnsched_class_idle (in >> >> > 2.5.x) is not feasible (we could not run any userland task in it >> >> > anyway), we'd better stick with SCHED_OTHER. >> >> > >> >> >> >> Thanks a lot for the feedback. Your suggestions simplified the patch. I >> >> also changed SCHED_IDLE to SCHED_OTHER since it might be more beneficial >> >> for the broader audience. Any other suggestions? >> > >> > For an even broader audience, the POSIX skin mutexes should be tracked >> > as well. >> > >> >> >> >> After applying this patch, a thread with priority 0 will automatically >> >> switch back to secondary mode after every (native) skincall unless the >> >> task holds a mutex (simple and nested). >> >> >> >> The benefit is, that the task with priority 0 (which I called a linux >> >> domain rt thread) >> > >> > Actually, no. This is not a rt thread at all, in the sense that you have >> > zero guarantee wrt latency in that case. Such a thread is actually a non >> > real-time Xenomai shadow thread, meaning that it may invoke Xenomai >> > services that require the caller to be a Xenomai thread, without >> > real-time support though. >> > >> >> can issue (native) skincalls and share resources with >> >> high prioritiy task. But it doesn't hold up Linux tasks unless it holds >> >> a mutex since it mostly runs in secondary mode and just switches to >> >> primary mode when needed. >> >> >> >> Just one more questions: Philippe said that you have something similar in >> >> 2.5. How do you enable it there? By setting the correct sheduling policy? >> >> >> > >> > There are plans to have it. That behavior would be enabled whenever the >> > linux policy is SCHED_OTHER, and the base priority is 0 Xenomai-wise. >> > The latter would be enough for now, but it seems more future-proof not >> > to assume that only SCHED_OTHER tasks could be assigned Xenomai priority >> > 0. >> > >> >> Is there any update on the plans to have Xenomai base priority 0 >> threads to be operating by default in relaxed mode? We are using 2.5.4 >> and currently apply the patch below as a workaround. The patch is >> similar to the 2.4 patch of Andreas in that it actively switches back >> base prio 0 shadowed threads into relaxed mode, but doesn't take any >> held locks into account. >> >> Please comment on this patch. If there is any preliminary code for >> 2.5.x available regarding this functionality I'll be happy to test it >> ;-) >> > > I have blackfin festivity to handle right now, but next in queue is this > issue. > > -- > Philippe. > > > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
