[PATCH] Add configuration option for single processor applications

[Richi Dubey]

This change sets the value of number of processor as 1 for a single processor 
application.
Useful when trying to run a single processor application on a multi processor 
scheduler.
---
 cpukit/include/rtems/confdefs/scheduler.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/cpukit/include/rtems/confdefs/scheduler.h 
b/cpukit/include/rtems/confdefs/scheduler.h
index 84ca810fd7..116b2aec87 100644
--- a/cpukit/include/rtems/confdefs/scheduler.h
+++ b/cpukit/include/rtems/confdefs/scheduler.h
@@ -45,6 +45,10 @@
 
 #include 
 
+#ifndef CONFIGURE_MAXIMUM_PROCESSORS
+  #define CONFIGURE_MAXIMUM_PROCESSORS 1
+#endif
+
 #if !defined(CONFIGURE_SCHEDULER_CBS) \
   && !defined(CONFIGURE_SCHEDULER_EDF) \
   && !defined(CONFIGURE_SCHEDULER_EDF_SMP) \
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Sebastian Huber]

On 16/03/2021 16:45, Richi Dubey wrote:


This change sets the value of number of processor as 1 for a single processor 
application.
Useful when trying to run a single processor application on a multi processor 
scheduler.
I think this patch is superfluous. In which scenario do you think it is 
necessary?


By default, exactly one processor is configured in all RTEMS build 
configurations.


See:

/* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP 
configurations */

#if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
  #define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
#else
  #define _CONFIGURE_MAXIMUM_PROCESSORS 1
#endif

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Richi Dubey]

Thanks for your quick review.

I think this patch is superfluous. In which scenario do you think it is
> necessary?

It is from this mail conversation:
https://lists.rtems.org/pipermail/devel/2020-September/061845.html
followed by
https://lists.rtems.org/pipermail/devel/2020-September/061846.html.

Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its declaration

at cpukit/include/rtems/scheduler.h. This addition would be necessary to
support future SMP schedulers that need to know the number of CPUs in the
system at the time of configuration.

>
>   /* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP
> configurations */
> #if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
>#define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
> #else
>#define _CONFIGURE_MAXIMUM_PROCESSORS 1
> #endif

I can see this in percpu.h. It's weird that make still gave an error!

On Tue, Mar 16, 2021 at 9:50 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 16/03/2021 16:45, Richi Dubey wrote:
>
> > This change sets the value of number of processor as 1 for a single
> processor application.
> > Useful when trying to run a single processor application on a multi
> processor scheduler.
> I think this patch is superfluous. In which scenario do you think it is
> necessary?
>
> By default, exactly one processor is configured in all RTEMS build
> configurations.
>
> See:
>
> /* Ensure that _CONFIGURE_MAXIMUM_PROCESSORS > 1 only in SMP
> configurations */
> #if defined(CONFIGURE_MAXIMUM_PROCESSORS) && defined(RTEMS_SMP)
>#define _CONFIGURE_MAXIMUM_PROCESSORS CONFIGURE_MAXIMUM_PROCESSORS
> #else
>#define _CONFIGURE_MAXIMUM_PROCESSORS 1
> #endif
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Sebastian Huber]

On 17/03/2021 19:00, Richi Dubey wrote:


Thanks for your quick review.

I think this patch is superfluous. In which scenario do you think
it is
necessary?

It is from this mail conversation:
https://lists.rtems.org/pipermail/devel/2020-September/061845.html 


followed by
https://lists.rtems.org/pipermail/devel/2020-September/061846.html 
.

For the tests you just need a temporary hack.


Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its 
declaration 
 
at cpukit/include/rtems/scheduler.h. This addition would be necessary 
to support future SMP schedulers that need to know the number of CPUs 
in the system at the time of configuration.
In general, it makes no sense to use an SMP scheduler on a system with 
just one processor. If you really want to do this, then you have to 
explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application 
configuration.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Gedare Bloom]

Hi Richi,

On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
 wrote:
>
> On 17/03/2021 19:00, Richi Dubey wrote:
>
> > Thanks for your quick review.
> >
> > I think this patch is superfluous. In which scenario do you think
> > it is
> > necessary?
> >
> > It is from this mail conversation:
> > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
> > 
> > followed by
> > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
> > .
> For the tests you just need a temporary hack.
> >
> > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
> > declaration
> > 
> > at cpukit/include/rtems/scheduler.h. This addition would be necessary
> > to support future SMP schedulers that need to know the number of CPUs
> > in the system at the time of configuration.

Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?

Why not just copy how SMP EDF deals with this problem?
https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124

I guess that is the "right way" to put the onus on the application to
specify their configuration properly.

> In general, it makes no sense to use an SMP scheduler on a system with
> just one processor. If you really want to do this, then you have to
> explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application
> configuration.
>

I never thought too much about this. I guess, it means we expect the
scheduler-specific tests do a sufficient job to exercise the scheduler
implementations that we can rely on the default scheduler to "just
work" in the other tests. Which makes sense although you have stumbled
over some scheduler-specific bugs that are uncovered by these
non-scheduler tests. Documenting your approach to developing and
debugging a scheduler may help the next person who tries. :) We don't
have a great place for that kind of guidance, so I guess clear blog
posts are helpful for now.

-Gedare
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Richi Dubey]

Hi!

Thanks for your review.

Why not just copy how SMP EDF deals with this problem?
>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
> I guess that is the "right way" to put the onus on the application to
> specify their configuration properly.

This seems like the right way and I completely understand. I am going to
use a similar strategy. btw line 125 exceeds the 80 char limit, is that
okay for header files?

I never thought too much about this. I guess, it means we expect the
> scheduler-specific tests do a sufficient job to exercise the scheduler
> implementations that we can rely on the default scheduler to "just
> work" in the other tests. Which makes sense although you have stumbled
> over some scheduler-specific bugs that are uncovered by these
> non-scheduler tests.

Yes, some of the errors in our Strong APA scheduler (code or logic) was
discovered by failing non scheduler tests.

> Documenting your approach to developing and
> debugging a scheduler may help the next person who tries. :) We don't
> have a great place for that kind of guidance, so I guess clear blog
> posts are helpful for now.

Okay, I am on it. *How to write a scheduler: RTEMS edition* coming soon on
https://rtemswithrichi.wordpress.com/ :p


On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom  wrote:

> Hi Richi,
>
> On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
>  wrote:
> >
> > On 17/03/2021 19:00, Richi Dubey wrote:
> >
> > > Thanks for your quick review.
> > >
> > > I think this patch is superfluous. In which scenario do you think
> > > it is
> > > necessary?
> > >
> > > It is from this mail conversation:
> > > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
> > > 
> > > followed by
> > > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
> > > .
> > For the tests you just need a temporary hack.
> > >
> > > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
> > > declaration
> > > <
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260
> >
> > > at cpukit/include/rtems/scheduler.h. This addition would be necessary
> > > to support future SMP schedulers that need to know the number of CPUs
> > > in the system at the time of configuration.
>
> Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?
>
> Why not just copy how SMP EDF deals with this problem?
>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>
> I guess that is the "right way" to put the onus on the application to
> specify their configuration properly.
>
> > In general, it makes no sense to use an SMP scheduler on a system with
> > just one processor. If you really want to do this, then you have to
> > explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application
> > configuration.
> >
>
> I never thought too much about this. I guess, it means we expect the
> scheduler-specific tests do a sufficient job to exercise the scheduler
> implementations that we can rely on the default scheduler to "just
> work" in the other tests. Which makes sense although you have stumbled
> over some scheduler-specific bugs that are uncovered by these
> non-scheduler tests. Documenting your approach to developing and
> debugging a scheduler may help the next person who tries. :) We don't
> have a great place for that kind of guidance, so I guess clear blog
> posts are helpful for now.
>
> -Gedare
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Gedare Bloom]

On Sun, Mar 21, 2021 at 11:48 PM Richi Dubey  wrote:
>
> Hi!
>
> Thanks for your review.
>
>> Why not just copy how SMP EDF deals with this problem?
>> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>> I guess that is the "right way" to put the onus on the application to
>> specify their configuration properly.
>
> This seems like the right way and I completely understand. I am going to use 
> a similar strategy. btw line 125 exceeds the 80 char limit, is that okay for 
> header files?
>

That depends. I don't think the CPP will handle string concatenation
so well, so a long string like that can cause an exception to the
rule. Otherwise you would end up with something like
  #ifndef CONFIGURE_MAXIMUM_PROCESSORS
#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \
configure the EDF SMP scheduler"
  #endif
which is worse. It might be possible through some other means though, like
#ifndef CONFIGURE_MAXIMUM_PROCESSORS
#error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \
"to configure the EDF SMP scheduler"
#endif

But again, it is probably better just to let it spill over length than
to make it more complex by this manner.

>> I never thought too much about this. I guess, it means we expect the
>> scheduler-specific tests do a sufficient job to exercise the scheduler
>> implementations that we can rely on the default scheduler to "just
>> work" in the other tests. Which makes sense although you have stumbled
>> over some scheduler-specific bugs that are uncovered by these
>> non-scheduler tests.
>
> Yes, some of the errors in our Strong APA scheduler (code or logic) was 
> discovered by failing non scheduler tests.
>>
>> Documenting your approach to developing and
>> debugging a scheduler may help the next person who tries. :) We don't
>> have a great place for that kind of guidance, so I guess clear blog
>> posts are helpful for now.
>
> Okay, I am on it. How to write a scheduler: RTEMS edition coming soon on 
> https://rtemswithrichi.wordpress.com/ :p

I think I wrote the first version of this :)
https://gedare.github.io/pdf/bloom_scheduling_2014.pdf
Now things are a little bit more complicated by SMP. Capturing this
knowledge is important.

>
>
> On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom  wrote:
>>
>> Hi Richi,
>>
>> On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
>>  wrote:
>> >
>> > On 17/03/2021 19:00, Richi Dubey wrote:
>> >
>> > > Thanks for your quick review.
>> > >
>> > > I think this patch is superfluous. In which scenario do you think
>> > > it is
>> > > necessary?
>> > >
>> > > It is from this mail conversation:
>> > > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
>> > > 
>> > > followed by
>> > > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
>> > > .
>> > For the tests you just need a temporary hack.
>> > >
>> > > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
>> > > declaration
>> > > 
>> > > at cpukit/include/rtems/scheduler.h. This addition would be necessary
>> > > to support future SMP schedulers that need to know the number of CPUs
>> > > in the system at the time of configuration.
>>
>> Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?
>>
>> Why not just copy how SMP EDF deals with this problem?
>> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
>>
>> I guess that is the "right way" to put the onus on the application to
>> specify their configuration properly.
>>
>> > In general, it makes no sense to use an SMP scheduler on a system with
>> > just one processor. If you really want to do this, then you have to
>> > explicitly define CONFIGURE_MAXIMUM_PROCESSORS to 1 in your application
>> > configuration.
>> >
>>
>> I never thought too much about this. I guess, it means we expect the
>> scheduler-specific tests do a sufficient job to exercise the scheduler
>> implementations that we can rely on the default scheduler to "just
>> work" in the other tests. Which makes sense although you have stumbled
>> over some scheduler-specific bugs that are uncovered by these
>> non-scheduler tests. Documenting your approach to developing and
>> debugging a scheduler may help the next person who tries. :) We don't
>> have a great place for that kind of guidance, so I guess clear blog
>> posts are helpful for now.
>>
>> -Gedare
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add configuration option for single processor applications

[Richi Dubey]

>
> That depends. I don't think the CPP will handle string concatenation
> so well, so a long string like that can cause an exception to the
> rule. Otherwise you would end up with something like
>   #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \
> configure the EDF SMP scheduler"
>   #endif
> which is worse. It might be possible through some other means though, like
> #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \
> "to configure the EDF SMP scheduler"
> #endif
> But again, it is probably better just to let it spill over length than
> to make it more complex by this manner.

I understand, Thanks for the clarification.

I think I wrote the first version of this :)
> https://gedare.github.io/pdf/bloom_scheduling_2014.pdf
> Now things are a little bit more complicated by SMP. Capturing this
> knowledge is important.

Got it. Thanks!



On Mon, Mar 22, 2021 at 11:08 PM Gedare Bloom  wrote:

> On Sun, Mar 21, 2021 at 11:48 PM Richi Dubey  wrote:
> >
> > Hi!
> >
> > Thanks for your review.
> >
> >> Why not just copy how SMP EDF deals with this problem?
> >>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
> >> I guess that is the "right way" to put the onus on the application to
> >> specify their configuration properly.
> >
> > This seems like the right way and I completely understand. I am going to
> use a similar strategy. btw line 125 exceeds the 80 char limit, is that
> okay for header files?
> >
>
> That depends. I don't think the CPP will handle string concatenation
> so well, so a long string like that can cause an exception to the
> rule. Otherwise you would end up with something like
>   #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined to \
> configure the EDF SMP scheduler"
>   #endif
> which is worse. It might be possible through some other means though, like
> #ifndef CONFIGURE_MAXIMUM_PROCESSORS
> #error "CONFIGURE_MAXIMUM_PROCESSORS must be defined" ## \
> "to configure the EDF SMP scheduler"
> #endif
>
> But again, it is probably better just to let it spill over length than
> to make it more complex by this manner.
>
> >> I never thought too much about this. I guess, it means we expect the
> >> scheduler-specific tests do a sufficient job to exercise the scheduler
> >> implementations that we can rely on the default scheduler to "just
> >> work" in the other tests. Which makes sense although you have stumbled
> >> over some scheduler-specific bugs that are uncovered by these
> >> non-scheduler tests.
> >
> > Yes, some of the errors in our Strong APA scheduler (code or logic) was
> discovered by failing non scheduler tests.
> >>
> >> Documenting your approach to developing and
> >> debugging a scheduler may help the next person who tries. :) We don't
> >> have a great place for that kind of guidance, so I guess clear blog
> >> posts are helpful for now.
> >
> > Okay, I am on it. How to write a scheduler: RTEMS edition coming soon on
> https://rtemswithrichi.wordpress.com/ :p
>
> I think I wrote the first version of this :)
> https://gedare.github.io/pdf/bloom_scheduling_2014.pdf
> Now things are a little bit more complicated by SMP. Capturing this
> knowledge is important.
>
> >
> >
> > On Thu, Mar 18, 2021 at 2:15 AM Gedare Bloom  wrote:
> >>
> >> Hi Richi,
> >>
> >> On Wed, Mar 17, 2021 at 1:06 PM Sebastian Huber
> >>  wrote:
> >> >
> >> > On 17/03/2021 19:00, Richi Dubey wrote:
> >> >
> >> > > Thanks for your quick review.
> >> > >
> >> > > I think this patch is superfluous. In which scenario do you
> think
> >> > > it is
> >> > > necessary?
> >> > >
> >> > > It is from this mail conversation:
> >> > > https://lists.rtems.org/pipermail/devel/2020-September/061845.html
> >> > >  >
> >> > > followed by
> >> > > https://lists.rtems.org/pipermail/devel/2020-September/061846.html
> >> > >  >.
> >> > For the tests you just need a temporary hack.
> >> > >
> >> > > Strong APA uses the value of CONFIGURE_MAXIMUM_PROCESSORS in its
> >> > > declaration
> >> > > <
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L260
> >
> >> > > at cpukit/include/rtems/scheduler.h. This addition would be
> necessary
> >> > > to support future SMP schedulers that need to know the number of
> CPUs
> >> > > in the system at the time of configuration.
> >>
> >> Can you use _CONFIGURE_MAXIMUM_PROCESSORS there?
> >>
> >> Why not just copy how SMP EDF deals with this problem?
> >>
> https://github.com/richidubey/rtems/blob/d3d1e4bc8e616738bd5892c59f82b174c399fc0b/cpukit/include/rtems/scheduler.h#L124
> >>
> >> I guess that is the "right way" to put the onus on the appli