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
