smp support

Gedare Bloom gedare at rtems.org
Thu Jan 11 15:09:18 UTC 2018


On Wed, Jan 10, 2018 at 8:48 PM, bin.wang at qkmtech.com
<bin.wang at qkmtech.com> wrote:
>
>> another question:
>>
>>  if i use the smp configuration macro define,am i still need to do the
>> mutiprocessor configuration macro define  for  confdef.h ?
>>
> With SMP you have to enable SMP when you configure/build RTEMS, and
> you need to provide the CPP configuration macros to set up the SMP
> system and schedulers.
>
>>> what the CPP means?
C Preprocessor.

Did you add an extra > character for your response? It is messing with
my email client, which interprets these as "reply" nesting...

>>>in CONFIGURING A SYSTEM chapter in c user doc, i find the two
>>> configurations items .  one is 24.22 SMP Specific Configuration Parameters
>>> ,another is 24.24 Multiprocessing Configuration
>>>what i want to ask is if i want to use smp, do i need use the
>>> Multiprocessing Configuration?  or i just need use SMP Specific
>>> Configuration Parameters and do not need care about >>the Multiprocessing
>>> Configuration.

You do not need to care about Multiprocessing Configuration.

>
> "SMP means all cores are treated equally by the operating system."
> "AMP means cores are not treated the same by the OS, which can cover a lot
> of heterogeneous behavior."
>>>i know what you said
>>>so the basic problem which confused me is the difference betweent
>>> Multiprocessing Configuration and SMP Configuration,  not the concept of amp
>>> and smp
>>>in my point of view ,no matter AMP or  SMP is  all called Multiprocessing
>>> because they all use the muticore .is it right ? so if i want to use AMP
>>> mode ,than i need >>just Multiprocessing Configuration?

There is not support for AMP out of the box with RTEMS as far as I
know. This "Multiprocessing Configuration" stuff is about how to run a
distributed system of multiple RTEMS images, one on each processor,
that share a global object namespace. It is not the same as how to run
a single RTEMS image that manages multiple processors.

>>>if i want to use SMP mode,than i need Multiprocessing Configuration and
>>> SMP Configuration ?
>
>
>
>
>
> ________________________________
> bin.wang at qkmtech.com
>
>
> From: Gedare Bloom
> Date: 2018-01-11 00:43
> To: bin.wang at qkmtech.com
> CC: Chris Johns; Users
> Subject: Re: Re: smp support
> On Fri, Dec 29, 2017 at 3:55 AM, bin.wang at qkmtech.com
> <bin.wang at qkmtech.com> wrote:
>> thanks
>>
>> but i still confused about the smp configuration and the mutiprocessor
>> configuration .
>>
>> for example. for zynq ,they has two arm core.   if i use the mutiprocessor
>> configuration , Is  rtems  use the two cores in amp mode ? is the rtems
>> manage the two cores? if rtems manages two cores,i think it is in smp mode
>> because  i think the concept of smp mode  is the one system can manage
>> muticores which are  same cpu architecture。this is conflictive for my
>> point
>> of view
>>
> SMP means all cores are treated equally by the operating system.
>
> AMP means cores are not treated the same by the OS, which can cover a
> lot of heterogeneous behavior.
>
> RTEMS provides SMP capability.
>
>>  i think amp mode is rtems run in one core, another core is bare-metal or
>> linux. but the mutiprocessor configuration let me confused, it said as
>> follows
>>
>> "The RTEMS multiprocessor execution model is multiple instruction streams
>> with multiple data
>> streams (MIMD). This execution model has each of the processors executing
>> code independent
>> of the other processors. Because of this parallelism, the application
>> designer can more easily
>> guarantee deterministic behavior."
>>
> This statement is true regardless of SMP/AMP: in either case, program
> code runs independent of other processors.
>
>> is it means one rtems system instance run in one core ,and another rtems
>> system instance  run in another core? and they can excute code
>> independent?
>> sorry, i think maybe i have some concept confused
>>
> One RTEMS instances executes across both cores, and both cores can
> execute code independent. It is possible for both cores to be
> executing OS functions simultaneously, or one core to execute OS code
> while another runs application, or both cores to execute application
> code in parallel.
>
>> if just one rtems run in two core , how to put code into different core to
>> run ? how to realize the parrallelism?
>>
> If you select RTEMS with SMP and provide scheduler with two cores, the
> scheduler will assign tasks/threads to the cores according to its
> scheduler policy/algorithm.
>
>> another question:
>>
>>  if i use the smp configuration macro define,am i still need to do the
>> mutiprocessor configuration macro define  for  confdef.h ?
>>
> With SMP you have to enable SMP when you configure/build RTEMS, and
> you need to provide the CPP configuration macros to set up the SMP
> system and schedulers.
>
>> ________________________________
>> bin.wang at qkmtech.com
>>
>>
>> From: Chris Johns
>> Date: 2017-12-29 14:21
>> To: bin.wang at qkmtech.com; Users
>> Subject: Re: smp support
>> On 29/12/17 12:16 pm, bin.wang at qkmtech.com wrote:
>>> thanks a lot .
>>>
>>> i have another question , if i use the smp, can i use the interrupt of
>>> rtems?
>>> which i want to interrupt period of hard real time of 125us.
>>>
>>
>> Yes you can.
>>
>>> i do not know the difference of the bare-metal interrupt and the rtems
>>> interrupt
>>> . is  the rtems interrupt have  performance loss of the hard real-time?
>>
>> The interrupt overhead will have the same overhead each time and its
>> deterministic behaviour will depend on the other interrupts in your system
>> and
>> their priority. The performance will depend on what you need to do in the
>> interrupt.
>>
>>>
>>> what the schedule method of smp use? is it can affect the interrupt
>>> performance?
>>>
>>
>> That depends on your application.
>>
>> Chris
>>
>>
>> _______________________________________________
>> users mailing list
>> users at rtems.org
>> http://lists.rtems.org/mailman/listinfo/users
>



More information about the users mailing list