Re: [Xenomai] mutate/start RT_TASK a posix thread?

[Philippe Gerum <rpm@xenomai.org>]

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 <rpm@xenomai.org>:
>>>
>>> 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 <rpm@xenomai.org>:
>>>>>
>>>>> On 07/31/2015 08:50 AM, Michael Haberler wrote:
>>>>>> Philippe,
>>>>>>
>>>>>>
>>>>>>> Am 30.07.2015 um 18:25 schrieb Philippe Gerum <rpm@xenomai.org>:
>>>>>>>
>>>>>>> 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.