Number of tasks

[leonp at plris.com]

Thanks a lot for clarification.
You saved me many doubts and hesitations - I always tried to keep the number 
of tasks small to increase the execution speed. But now, I need more tasks 
and was forced to study the issue more deeply.

Thanks again.

On Tuesday, 14 בMarch 2006 01:06, Chris Johns wrote:
> 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

-- 
Dr.Leon M.Pollak
Director
PLR Information Systems Ltd.