[Xenomai-help] Maximum number of realtime tasks

[Xenomai-help] Maximum number of realtime tasks

[Frits de Klark]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Hello everyone,

I'm thinking about implementing a tcp/ip socket server where I assign each
incoming connection 2 realtime tasks; 1 one for transmitting data and 1 for
receiving data. I'm aware of the fact that the tasks will lose their
realtime capacities, but I want to do some tests nonetheless.
I was wondering if there is a limit on the number of realtime tasks I can
allocate and run at the same time. Is there any?
And may there be other problems to expect?

Thanks very much for your help,

Frits

[-- Attachment #2: Type: text/html, Size: 542 bytes --]

Re: [Xenomai-help] Maximum number of realtime tasks

[Philippe Gerum]

On Tue, 2006-10-31 at 09:51 +0100, Frits de Klark wrote:
> Hello everyone,
> 
> I'm thinking about implementing a tcp/ip socket server where I assign
> each incoming connection 2 realtime tasks; 1 one for transmitting data
> and 1 for receiving data. I'm aware of the fact that the tasks will
> lose their realtime capacities, but I want to do some tests
> nonetheless.
> I was wondering if there is a limit on the number of realtime tasks I
> can allocate and run at the same time. Is there any?

No limit on the number of concurrent tasks. Just make sure to have
enough TCB space available from the Xenomai system heap
(CONFIG_XENO_OPT_SYS_HEAP).

>  
> And may there be other problems to expect?

Depending on the runtime behaviour of your system, i.e. large number of
ready-to-run tasks or outstanding timers at any given time, you may want
to experiment with the scalability options from the nucleus
configuration section.

> Thanks very much for your help,
> 
> Frits
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.

Re: [Xenomai-help] Maximum number of realtime tasks

[Gilles Chanteperdrix]

Frits de Klark wrote:
> Hello everyone,
> 
> I'm thinking about implementing a tcp/ip socket server where I assign 
> each incoming connection 2 realtime tasks; 1 one for transmitting data 
> and 1 for receiving data. I'm aware of the fact that the tasks will lose 
> their realtime capacities, but I want to do some tests nonetheless.
> I was wondering if there is a limit on the number of realtime tasks I 
> can allocate and run at the same time. Is there any?
> And may there be other problems to expect?
> 
> Thanks very much for your help,

Pay attention to the stack size of the user-space tasks: the default of
8 Megabytes will exhaust your RAM rapidly. So, you should either :
- set the default stack size with ulimit;
- or set the the stack size of the created threads, but in this case the
main thread will have an 8 Megabytes stack.

In order to set the stack size of a thread, use
pthread_attr_setstacksize if using the POSIX skin or the stksize 
parameter of rt_task_create if using the native skin.

-- 
                                                  Gilles Chanteperdrix

RE: [Xenomai-help] Maximum number of realtime tasks

[Daniel Schnell]

Gilles Chanteperdrix wrote:
> 
> Pay attention to the stack size of the user-space tasks: the default
> of 8 Megabytes will exhaust your RAM rapidly. So, you should either :
> - set the default stack size with ulimit;
> - or set the the stack size of the created threads, but in this case
> the main thread will have an 8 Megabytes stack. 
> 
> In order to set the stack size of a thread, use
> pthread_attr_setstacksize if using the POSIX skin or the stksize
> parameter of rt_task_create if using the native skin.  

If I set the stacksize generally via ulimit -s and additionally via the
pthread_attr_setstacksize() how is the precedence of one of these calls
over the other ? Does pthread_attr_setstacksize

Re: [Xenomai-help] Maximum number of realtime tasks

[Gilles Chanteperdrix]

Daniel Schnell wrote:
> Gilles Chanteperdrix wrote:
> 
>>Pay attention to the stack size of the user-space tasks: the default
>>of 8 Megabytes will exhaust your RAM rapidly. So, you should either :
>>- set the default stack size with ulimit;
>>- or set the the stack size of the created threads, but in this case
>>the main thread will have an 8 Megabytes stack. 
>>
>>In order to set the stack size of a thread, use
>>pthread_attr_setstacksize if using the POSIX skin or the stksize
>>parameter of rt_task_create if using the native skin.  
> 
> 
> If I set the stacksize generally via ulimit -s and additionally via the
> pthread_attr_setstacksize() how is the precedence of one of these calls
> over the other ? Does pthread_attr_setstacksize

Setting the stack size with pthread_attr_setstacksize seems to allow a
stack greater than the limit fixed by ulimit, but I do not think it is
wise to rely on such a behaviour.

-- 
                                                  Gilles Chanteperdrix

RE: [Xenomai-help] Maximum number of realtime tasks

[Daniel Schnell]

Gilles Chanteperdrix wrote:

> Setting the stack size with pthread_attr_setstacksize seems to allow
> a stack greater than the limit fixed by ulimit, but I do not think it
> is wise to rely on such a behaviour.  

If one wants to have always the same stack size for every thread than
ulimit -s would be probably the way to go. But often in Realtime
applications it is the preferred way of setting  the stack size
individually, so one doesn't waste too much memory. A mixture of both
seems to be tempting: setting a general stack size and individually
change it. So why not rely on this ? Which part in the system actually
creates the stack for a Xenomai task and how is the interaction between
Linux and Xenomai to derive the general system wide stack limit to a
Xenomai task ?

Is there a way to find out, which thread has which stack size ?

Daniel

Re: [Xenomai-help] Maximum number of realtime tasks

[Gilles Chanteperdrix]

Daniel Schnell wrote:
> Gilles Chanteperdrix wrote:
> 
> 
>>Setting the stack size with pthread_attr_setstacksize seems to allow
>>a stack greater than the limit fixed by ulimit, but I do not think it
>>is wise to rely on such a behaviour.  
> 
> 
> If one wants to have always the same stack size for every thread than
> ulimit -s would be probably the way to go. But often in Realtime
> applications it is the preferred way of setting  the stack size
> individually, so one doesn't waste too much memory. A mixture of both
> seems to be tempting: setting a general stack size and individually
> change it. So why not rely on this ? Which part in the system actually
> creates the stack for a Xenomai task and how is the interaction between
> Linux and Xenomai to derive the general system wide stack limit to a
> Xenomai task ?

The way I understand ulimit (or the setrlimit syscall), it should be
used to set a maximum limit, so the fact that pthread_attr_setstacksize
allow to bypass this limit may be a bug that may be corrected one day.
So, I repeat, I would not rely on this behaviour.

> 
> Is there a way to find out, which thread has which stack size ?

Each thread stack is set up as a mapping in /proc/pid/maps, so if you
know one address on each stack, you may find out which thread has
which stack. Ok, it is not easy, but I know no other way.

-- 
                                                  Gilles Chanteperdrix

RE: [Xenomai-help] Maximum number of realtime tasks

[Daniel Schnell]

Gilles Chanteperdrix wrote:
> 
> Pay attention to the stack size of the user-space tasks: the default 
> of 8 Megabytes will exhaust your RAM rapidly. So, you should either :
> - set the default stack size with ulimit;
> - or set the the stack size of the created threads, but in this case 
> the main thread will have an 8 Megabytes stack.
> 
> In order to set the stack size of a thread, use 
> pthread_attr_setstacksize if using the POSIX skin or the stksize 
> parameter of rt_task_create if using the native skin.

If I set the stacksize generally via ulimit -s and additionally via the
pthread_attr_setstacksize() how is the precedence of one of these calls
over the other ? Does pthread_attr_setstacksize() "overwrite" the stack
size limitation of ulimit -s ?

Daniel.