> Am 31.07.2015 um 16:07 schrieb Philippe Gerum <[email protected]>: > > On 07/31/2015 11:21 AM, Michael Haberler wrote: >> Philippe, >> >> this is excellent news because this means the scheme would work _and_ >> improve versatility. >> >> I have only an optimization question left: >> >>> Am 31.07.2015 um 10:22 schrieb Philippe Gerum <[email protected]>: >>> >>> On 07/31/2015 08:50 AM, Michael Haberler wrote: >>>> Philippe, >>>> >>>> >>>>> Am 30.07.2015 um 18:25 schrieb Philippe Gerum <[email protected]>: >>>>> >>>>> On 07/30/2015 07:26 AM, Michael Haberler wrote: >>>>>> we're happily using RT threads using the Xenomai 2 thread API >>>>>> >>>>>> is it possible _using this API_ to create/mutate/relax such a thread >>>>>> intentionally into a Posix thread but retaining the API usage? >>>>> >>>>> It is possible to run them as low priority Xenomai threads, assigning >>>>> them to the SCHED_OTHER class. The native API is retained for those >>>>> threads, but their main runtime mode is relaxed, i.e. the co-kernel >>>>> makes sure to switch them back to relaxed mode automatically before >>>>> returning to user-space from a syscall which required a switch to >>>>> primary mode. >>>> >>>> that would give us 'low-priority RT (SCHED_OTHER)' threads which is >>>> already a great improvement for us, and it would be simple to do as you >>>> outlined in the followup mail >>>> >>>> >>>> taking things one step further (I'm unsure about the precise semantics of >>>> 'relaxed mode', so far I understood it as 'behaves like a normal Linux >>>> thread'): >>> >>> By relaxed, I mean scheduled by the regular kernel as any other >>> non-Xenomai thread, not by the Xenomai scheduler. As a consequence of >>> this, no rt guarantee, no pressure for very short response time. >>> >>>> >>>> would such a SCHED_OTHER-class thread be able to use _any_ system calls >>>> like a normal Linux thread? like file I/O, sockets, poll, etc? >>>> >>> >>> Yes. The only issue to care about is not passing file descriptors >>> obtained by the Xenomai open() call to regular Linux I/O services. The >>> converse works with the POSIX API though, since the Xenomai I/O >>> subsystem hands over requests for fds it does not own to the >>> corresponding glibc call. >> >> not an issue since Xenomai file descriptors not used, but good to know >> >>> >>>> if so - are there any side effects I should be aware of? >>>> >>> >>> None. However, switching a non-rt Xenomai thread back and forth between >>> the Xenomai and Linux sides involves several scheduling operations each >>> time (one less for 3.x compared to 2.x though). Therefore, it is better >>> if the low priority thread does not have to do this at a high rate, it's >>> faily costly CPU-wise. >> >> I just went through the code to see which native services are used post >> creation: >> >> every thread cycle: >> rt_task_wait_period() >> rt_timer_read(). >> rt_task_self() (unsure, need to check usage) >> >> rarely: >> rt_task_inquire() >> rt_task_suspend() >> rt_task_resume() >> >> at thread exit: rt_task_delete() rt_task_join() but I guess not relevant >> >> Assuming your load concern applies for these calls likewise, I see two >> options: >> >> a) since the relax would happen intentionally through a startup option, I >> could have the thread check its descriptor and figure 'I better avoid native >> services' and use equivalent non-RT Linux services >> b) if there is a cheap way of introspecting on the 'am I a relaxed thread?' >> property of a thread I could make the conditional API usage self-contained, >> i.e. without reference to our task descriptor; and it would help reducing >> API breakage. >> >> I assume rt_task_self() is the right one. Do you think that is cheap enough >> to pursue option b) ? >> >> > > rt_task_self() would return a valid descriptor for both SCHED_OTHER and > SCHED_FIFO threads, provided they are Xenomai threads. You need > something cheap that would quickly tell the caller about its > capabilities as a Xenomai thread instead. > > With 2.x, you could hack that check with xeno_get_current_mode(), which > is part of the internal API, testing the XNOTHER bit there. Have a look > at src/skins/native/mutex.c for some examples. XNOTHER is armed for > Xenomai-managed SCHED_OTHER threads. This only entails a plain memory > reference, so this is cheap enough. Granted, this is an internal call, > so no guarantee for backward compat. But Xenomai 2.x is virtually EOL > already, there will be no 2.7, so that feature is there to stay > indefinitely.
fine, I'll manage that. any suggestions for Xenomai 3? If too hairy, I'll go for the 'inspect our own thread descriptor' option. thanks, - Michael > > -- > Philippe. _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
