SMP related question

Wed Aug 22 10:43:19 UTC 2018

Hi all,

My main objective was to have a way to run the rtems testsuite and have a script auto-compare the results with the corresponding scn file.
Currently, just because core0 starts core1, seems like core1 always starts Init(), all results are flipped, thus this process cannot be automated.
Functionality wise, everything runs as expected, I verified individually each core with the debugger, so I am ok with it.

Also, this issue comes up in a different form also when the applications exits, because core1 (that had started Init(), exits with the expected return code, while all other cores terminate with RTEMS_FATAL_SOURCE_SMP/SMP_FATAL_SHUTDOWN_RESPONSE, which is handled as an error at the moment from the debugger/loader. For the moment I have added a fatal extension handler to avoid this case, but I am still looking if there is any better solution.

Best Regards,
   Stavros

From: users [mailto:users-bounces at rtems.org] On Behalf Of Joel Sherrill
Sent: Monday, August 20, 2018 5:39 PM
To: Sebastian Huber <sebastian.huber at embedded-brains.de>
Cc: rtems-users at rtems.org <users at rtems.org>
Subject: Re: SMP related question

On Mon, Aug 20, 2018 at 1:23 AM, Sebastian Huber <sebastian.huber at embedded-brains.de<mailto:sebastian.huber at embedded-brains.de>> wrote:

On 12/08/18 00:41, Chris Johns wrote:
On 10/08/2018 22:30, Sebastian Huber wrote:
Hello Stavros,

you can do this with a custom clustered scheduler configuration:

https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#clustered-scheduler-configuration
I had a brief look over the documentation you provided but could not see how to
achieve the result you are saying.

Stavros, asked for two things.

1. A way to change properties of the initialization task which are not covered by configuration options

https://docs.rtems.org/branches/master/c-user/configuring_a_system.html#classic-api-initialization-tasks-table-configuration

before the initialization task runs. To do this some user provided code must execute after the initialization task is created and before it runs. My suggestion to use a device driver initialization function for this doesn't work. The initialization task is created after the device driver initialization. It can be done via a system initialization handler using the undocumented RTEMS_SYSINIT_ITEM(). Maybe also a high priority constructor, however, in this case the task already runs.

The high priority constructor is too late if the goal is to avoid any activity except core 0.

RTEMS_SYSINIT_ITEM() would work but adding a confdefs.h item for SMP configurations to pin the thread to a single core seems like a simple solution.

2. A way to pin a task to a particular processor. There are two options to do this in RTEMS. One is a clustered scheduler configuration, the other is the use of a thread to processor affinity.

I think being able to pin the Init thread to a single core would be a nice confdefs.h feature. Not specifying a full cpuset, just the core number.

I don't think this use case is enough by itself to force a user to clustered scheduling with core 0 an instance by itself.

Alternatively, on a recent version the default SMP scheduler supports a one-to-one affinity.  You can set it in a device driver.
Is there an example of how to do this?

As Sebastian points out, you can't do it in a device driver. But no, there is no example specifically for the Init thread.
There are smptests which do this but likely no proper example of setting affinity, scheduler, etc.

--joel

Chris
----- Am 10. Aug 2018 um 14:10 schrieb Passas, Stavros stavros.passas at intel.com<mailto:stavros.passas at intel.com>:
Hi,

In my local SMP enabled RTEMS, I notice core1 starting the Init() function of
the user application.
Is there a way to enforce RTEMS to run the Init() in the boot processor, when
SMP is enabled?

Best Regards,
   Stavros
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.

_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users
_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users
_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de<mailto:sebastian.huber at embedded-brains.de>
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
users mailing list
users at rtems.org<mailto:users at rtems.org>
http://lists.rtems.org/mailman/listinfo/users

--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180822/79ee7283/attachment-0002.html>