Number of tasks

[Chris Johns]

leonp at plris.com wrote:
> 
> I shall be glad if somebody of RTEMS gurus will answer the following question:
> 
> Does the total number of tasks in the system influence somehow on the system 
> performance?

I assume you mean the time to switch tasks rather than the amount of 
work that can be performed.

The number of tasks should not effect performance. There are a number of 
ways the switch time can be altered from the basic or default RTEMS 
configuration. If you have user extensions hooking the switch handler 
this can effect the switch time, eg stack checker or capture engine. The 
use of task variables can change the switch time and in unpredictable 
ways. This is why they should not be used in RTEMS code, eg web server, 
shell, telnet ftp etc. Applications may use them for compatibility 
reasons how-ever in this case it is your problem to resolve rather than 
RTEMS changing something on you.

> 
> My code study shows that task switch time is not influenced. Am I right?
>

Yes.

> 
> And what IS influenced?
> 

Mostly memory and also the time creating or deleting a task *may* vary. 
Memory is the work-space memory for the task object plus extra memory 
for the FP area if enabled for the task, and the stack. There could be 
more. These are all separate allocations and so the time depends on the 
way the work-space allocator works. The unlimited objects flag can also 
change things. If you are using this flag the task create code has extra 
work to manage the growing and shrinking of the tables used by task 
objects. The design of this code is an extension of the original code 
and does not make the best use of memory but does maintain the 
deterministic performance once the table has been grown. When growing a 
new table is allocated from the work-space and the current table copied. 
This all changes the time to create a task and requires you have the 
space to allocation the new table. The task object count helps smooth 
the bumps the unlimited flag can create. If the unlimited flag is not 
used the create and delete performance it almost deterministic (stack 
space allocation).

I once had an application that allowed me to play with some the upper 
limits. Pushing the application I created 300 sockets and 900 threads on 
a Coldfire with 16M RAM, and 2000 sockets and many thousands of threads 
on the PC BSP. The application ran normally and with no noticeable 
performance issue once everything was created. I did not activate all 
sockets and threads with this many, but I did test the application 
performance and did not see any difference.

Regards
Chris