From mboxrd@z Thu Jan 1 00:00:00 1970 References: <09EA8A4C-D8EB-4470-A339-C2019D1B662B@gmail.com> <55BA500F.8010504@xenomai.org> <55BB305C.9000702@xenomai.org> <55BB8129.8040807@xenomai.org> <55BB95CE.4020906@xenomai.org> From: Philippe Gerum Message-ID: <55BB99F6.8090501@xenomai.org> Date: Fri, 31 Jul 2015 17:53:26 +0200 MIME-Version: 1.0 In-Reply-To: <55BB95CE.4020906@xenomai.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] mutate/start RT_TASK a posix thread? List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Haberler Cc: xenomai On 07/31/2015 05:35 PM, Philippe Gerum wrote: > On 07/31/2015 05:17 PM, Michael Haberler wrote: >> >>> Am 31.07.2015 um 16:07 schrieb Philippe Gerum : >>> >>> 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 : >>>>> >>>>> On 07/31/2015 08:50 AM, Michael Haberler wrote: >>>>>> Philippe, >>>>>> >>>>>> >>>>>>> Am 30.07.2015 um 18:25 schrieb Philippe Gerum : >>>>>>> >>>>>>> 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. >> > > 3.x has cobalt_get_current_mode() from lib/cobalt/current.h, testing for > XNWEAK will do the trick. > I have just exported cobalt_thread_mode() in the upcoming 3.0, which returns the runtime mode/state bits for the caller. This is still part of an internal API, so there won't be any ABI/API compat guarantees with future releases. This said, I don't see how libcobalt could do without it either ATM. Unlike lib/cobalt/current.h which is not installed, sys/cobalt.h is and including it will pull the proper declarations for any application to use cobalt_thread_mode(). -- Philippe.