Revisiting Minimum with Static Allocation

[Joel Sherrill]

On Thu, Feb 11, 2021 at 3:04 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 10/02/2021 21:36, Gedare Bloom wrote:
>
> >
> >
> > On Wed, Feb 10, 2021 at 10:57 AM Joel Sherrill <joel at rtems.org
> > <mailto:joel at rtems.org>> wrote:
> >
> >     Hi
> >
> >     The minimum sample is intended to show how to construct the
> >     minimum footprint RTEMS application. I suspect that with
> >     Sebastian's recent work on static allocation and reducing
> >     footprint, the minimum sample may be able to benefit from tweaking.
> >
> >     I just checked rtl22xx_t and it is < 16K code and 272 bytes of
> >     data. :)
> >
> >     Hello tends to be in the 64K range. Perhaps a static allocation
> >     hello variant.
> >
> >     Just wanting users to have good examples. A discussion at the
> >     Flight Software Workshop mentioned RTEMS was big but it doesn't
> >     seem to be if you look at executables which reflect those minimum
> >     feature sets.
> >
> >     Hoping Sebastian has magic settings to apply so these numbers are
> >     as good as possible.
> >
> > This is a good idea. A "useful" minimum configuration with static
> > objects, or maybe even a couple of them, could be helpful to identify
> > reasonable bottom ends of the spectrum we can conceivably support.
>
> For the pre-qualification project we have to deliver some resource usage
> information. We would like to provide some benchmark programs and some
> rules to estimate the resource usage based on configuration options.
> Example benchmark programs:
>
> 1. one one task with an infinite loop, no clock driver
>
> 2. one one task with an infinite loop, with clock driver
>
> 3. 2. +  create a second task
>
> 4. 3. + send/receive events
>
> 5. 3. + sem obtain/release
>
> 6. 3. + msg send/receive
>
> 7. 3. + barrier wait/release
>

This is a good list but size measurement is always a pain. Architecture is
fixed for you but  ARM vs Thumb or SPARC vs their REX makes a big deal
and probably 2x since I think the erc32 minimum exe is ~28-32k where
rtl22xx_t is half that.

Using -Os can shrink things 10-12% based on history.

RTEMS options matter. Will the threads be statically constructed?
Will the init thread also be the idle thread?
SMP or uniprocessor?
Will you use the simple scheduler?
Or the default uniprocessor one?  Lower the maximum priorities?
Include a filesystem or not?

I recall one closed source RTEMS used to publish the size info that
didn't include the BSP. We could do this by "ld -r" against librtemscpu.a
and the application. At least reporting this size vs linked exe highlights
how some BSPs are just larger due to hardware complexity.

There is nothing wrong with what you listed. It is perfectly appropriate
for a qualification effort where many of the things I listed above are
held constant.

But I started this thread because I heard someone say RTEMS minimum
executable size was on the order of 100K where Zephyr was 10K. That is
likely comparing apples to oranges But I'd like to have some well
characterized cases that show we really do get down to that range. Yes
it would require cherry picking some of the parameters

+ Architecture: Thumb
+ GCC flags: -Os (maybe more)
+ RTEMS configuration: signals off? uniprocessor
+ What application?
    - static init? Init as idle?
    - Scheduler choice? Simple should be smaller.

When someone asks size of hello world (not on your list), the other
RTOS likely has console only output (printk) and not a robust POSIX
stack with stdio, termios, etc. Andt hen there is the choice of printf,
iprintf, or printk.

I think your list is great but I think we also need a true minimum
application that sets the bottom limit.


> ...
>
> Print sizeof(obj) for various objects.
>

This is spsize. Hopefully it can be updated/moved to meet their purposes.

Having a single directory of all these characterization tests is great. And
eventually having a larger set and corresponding documentation to explain
the delta between each one is important.

--joel


>
> >     --joel
> >     _______________________________________________
> >     devel mailing list
> >     devel at rtems.org <mailto:devel at rtems.org>
> >     http://lists.rtems.org/mailman/listinfo/devel
> >     <http://lists.rtems.org/mailman/listinfo/devel>
> >
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210211/df2db087/attachment.html>