Re: [Xenomai] posix skin pthread_create issue

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 09/17/2012 11:02 PM, Gilles Chanteperdrix wrote:

> On 09/17/2012 10:46 PM, Pierre Quelin wrote:
> 
>>
>> Le 17/09/2012 21:50, Gilles Chanteperdrix a écrit :
>>> On 09/17/2012 09:32 PM, Pierre Quelin wrote:
>>>
>>>>>>>> After your answer, I try xenomai 2.6.1 and I increase the size of the
>>>>>>>>     private stack pool from 128 to 2048 with the same result.
>>>>>>>>
>>>>>>>> Is there any limits for the number of threads in Xenomai ?
>>>>>>> Not that I know of. There are only a few dynamic allocations in the
>>>>>>> various pools you already mentioned. The corresponding options are:
>>>>>>> XENO_OPT_REGISTRY_NRSLOTS (maximum number of objects in the registry,
>>>>>>> each thread is registered in the registry)
>>>>>>> XENO_OPT_SYS_HEAPSZ (system heap, used for various calls to xnmalloc)
>>>>>>> XENO_OPT_SEM_HEAPSZ (semaphore heap, use for allocating 4 bytes per
>>>>>>> thread + 4 bytes per mutex)
>>>>>>>
>>>>>>> But anyway, debugging the issue you have should be relatively easy by
>>>>>>> adding printfs/printks, starting from src/skins/posix/thread.c (function
>>>>>>> __wrap_pthread_create), continuing in ksrc/skins/posix/syscall.c,
>>>>>>> function __pthread_create, etc...
>>>>>> I try to obtain information about my context but all seems to be ok.
>>>>> You have to put a "pause" after the failing call to pthread_create,
>>>>> because otherwise if calling exit, when the process fails, all the
>>>>> memory it allocated in the various pools is freed.
>>>> I found the problem. It seems that the private sem heap is to small.
>>>>
>>>> I'm not sure about which parameter to increase in kernel menu so at
>>>> first I increase :
>>>
>>> "private sem heap" -> "private semaphores heap", how can this not be clear?
>> This link is clear, but I don't understand the link between "private 
>> semaphores heap", "global semaphores heap" and "system heap" ?
>> I just try to fix the right values for my context and my application.
> 
> 
> There is no link between the various heaps, which is the reason why they
> have separate configuration options. Now if the question is to know how
> much space in each heap consumes a thread, a mutex, etc... I guess
> nobody ever did the computation. For the semaphore heaps at least it is
> clear: each thread consumes 4 bytes in the semaphore heap, each mutex
> consumes 4 bytes in the private or global heap depending on whether it
> is a process-private, or global mutex (for posix mutexes, this is
> related to pthread_mutexattr_setpshared).
> 
>>>> ? Is calling pthread_set_mode_np (PTHREAD_WARNSW, 0) inhibits the rise
>>>> of the signal for a page fault?
>>>
>>> Yes, it inhibits the rise of the signal for any cause of switch to
>>> secondary mode. Quoting the documentation:
>>>
>>> "PTHREAD_WARNSW, when set, cause the signal SIGXCPU to be sent to the
>>> current thread, whenever it involontary switches to secondary mode;"
>>>
>>> so, obviously, when clear, the SIGXCPU is NOT SENT to the current thread
>>> whenever it involontary switches to secondary mode. What else did you
>>> understand when reading this documentation ?
>>
>> I don't understand that a page fault is 'just' a switch to secondary mode.
> 
> 
> A switch to secondary mode is devastating for a real-time thread running
> in primary mode.
> A page fault causes a switch to secondary mode so that the Linux kernel
> can handle the page fault, the only alternative is probably crashing, or
> suspending the thread that had the fault. SIGXCPU is sent, if you
> enabled the PTHREAD_WARNSW bit.
> 
> So, PTHREAD_WARNSW should be armed for threads which should stay in
> primary mode. The critical ones.
> 
> Anyway, it is not really normal to have page faults, using mlockall and
> the disabling of on-demand mappings by the I-pipe patch should prevent
> page faults from happening. So, it would be interesting to know what
> cause these faults.


Again, due to the C++ static objects constructors "feature", it may 
simply be that you start using Xenomai before the call to mlockall, and 
you simply somehow fail to see the signal sent by Xenomai, because it 
is also SIGXCPU and the handler you installed does not check the reason 
sent by Xenomai, for instance, the following commit, fixes exactly this 
issue for the latency test:

http://git.xenomai.org/?p=xenomai-2.6.git;a=commitdiff;h=d8c2bccce5de41a4b183c9a140dc12b0a2606261;hp=9afc3bce3770089083fa5d1bca596b53f5c7d058

-- 
                                                                Gilles.