Number of tasks
chrisj at rtems.org
Mon Mar 13 23:06:01 UTC 2006
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
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?
> 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
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.
More information about the users