Re: [PATCH rtems-tools] bsps/a53_*: Fix typo in qemu options
Hi Kinsey,
Thanks for reviewing the patch...
On Sun, Nov 15, 2020 at 9:51 AM Kinsey Moore
wrote:
> Odd, "gic_version" works just fine in the version of qemu-system-aarch64
> in the Debian package repos which is what I've been testing against. As
> you've provided in the patch, the official option name is "gic-version" and
> that also works. Just out of curiosity, does this cause Qemu to fail for
> you?
Qemu 5.0 crashes with:
```
qemu-system-aarch64: Property '.gic_version' not found
```
>
>
Either way, this change looks good to me.
>
Thanks, I'll push.
Best regards,
Vijay
>
> Kinsey
>
> -Original Message-
> From: devel On Behalf Of Vijay Kumar Banerjee
> Sent: Saturday, November 14, 2020 14:51
> To: devel@rtems.org
> Subject: [PATCH rtems-tools] bsps/a53_*: Fix typo in qemu options
>
> ---
> tester/rtems/testing/bsps/a53_ilp32_qemu.ini | 2 +-
> tester/rtems/testing/bsps/a53_lp64_qemu.ini | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> index 6dfc883..3beba06 100644
> --- a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> +++ b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> @@ -35,4 +35,4 @@
> bsp = a53_ilp32_qemu
> arch = aarch64
> tester= %{_rtscripts}/qemu.cfg
> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096
> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> +virt,gic-version=3 -cpu cortex-a53 -m 4096
> diff --git a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> index f29ab13..1b89284 100644
> --- a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> +++ b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> @@ -35,4 +35,4 @@
> bsp = a53_lp64_qemu
> arch = aarch64
> tester= %{_rtscripts}/qemu.cfg
> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096
> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> +virt,gic-version=3 -cpu cortex-a53 -m 4096
> --
> 2.21.1
>
> ___
> 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 rtems-tools] bsps/a53_*: Fix typo in qemu options
On Sun, Nov 15, 2020 at 8:37 AM Vijay Kumar Banerjee wrote:
>
> Hi Kinsey,
>
> Thanks for reviewing the patch...
>
> On Sun, Nov 15, 2020 at 9:51 AM Kinsey Moore wrote:
>>
>> Odd, "gic_version" works just fine in the version of qemu-system-aarch64 in
>> the Debian package repos which is what I've been testing against. As you've
>> provided in the patch, the official option name is "gic-version" and that
>> also works. Just out of curiosity, does this cause Qemu to fail for you?
>
> Qemu 5.0 crashes with:
> ```
> qemu-system-aarch64: Property '.gic_version' not found
> ```
>
>>
>>
>>
>> Either way, this change looks good to me.
>
>
> Thanks, I'll push.
>
Yes, the change looks good. Go ahead.
> Best regards,
> Vijay
>>
>>
>> Kinsey
>>
>> -Original Message-
>> From: devel On Behalf Of Vijay Kumar Banerjee
>> Sent: Saturday, November 14, 2020 14:51
>> To: devel@rtems.org
>> Subject: [PATCH rtems-tools] bsps/a53_*: Fix typo in qemu options
>>
>> ---
>> tester/rtems/testing/bsps/a53_ilp32_qemu.ini | 2 +-
>> tester/rtems/testing/bsps/a53_lp64_qemu.ini | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
>> b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
>> index 6dfc883..3beba06 100644
>> --- a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
>> +++ b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
>> @@ -35,4 +35,4 @@
>> bsp = a53_ilp32_qemu
>> arch = aarch64
>> tester= %{_rtscripts}/qemu.cfg
>> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
>> virt,gic_version=3 -cpu cortex-a53 -m 4096
>> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
>> +virt,gic-version=3 -cpu cortex-a53 -m 4096
>> diff --git a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
>> b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
>> index f29ab13..1b89284 100644
>> --- a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
>> +++ b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
>> @@ -35,4 +35,4 @@
>> bsp = a53_lp64_qemu
>> arch = aarch64
>> tester= %{_rtscripts}/qemu.cfg
>> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
>> virt,gic_version=3 -cpu cortex-a53 -m 4096
>> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
>> +virt,gic-version=3 -cpu cortex-a53 -m 4096
>> --
>> 2.21.1
>>
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-tools] bsps/a53_*: Fix typo in qemu options
On Sun, Nov 15, 2020 at 11:17 PM Gedare Bloom wrote:
> On Sun, Nov 15, 2020 at 8:37 AM Vijay Kumar Banerjee
> wrote:
> >
> > Hi Kinsey,
> >
> > Thanks for reviewing the patch...
> >
> > On Sun, Nov 15, 2020 at 9:51 AM Kinsey Moore
> wrote:
> >>
> >> Odd, "gic_version" works just fine in the version of
> qemu-system-aarch64 in the Debian package repos which is what I've been
> testing against. As you've provided in the patch, the official option name
> is "gic-version" and that also works. Just out of curiosity, does this
> cause Qemu to fail for you?
> >
> > Qemu 5.0 crashes with:
> > ```
> > qemu-system-aarch64: Property '.gic_version' not found
> > ```
> >
> >>
> >>
> >>
> >> Either way, this change looks good to me.
> >
> >
> > Thanks, I'll push.
> >
> Yes, the change looks good. Go ahead.
>
> Pushed! Thanks.
> > Best regards,
> > Vijay
> >>
> >>
> >> Kinsey
> >>
> >> -Original Message-
> >> From: devel On Behalf Of Vijay Kumar Banerjee
> >> Sent: Saturday, November 14, 2020 14:51
> >> To: devel@rtems.org
> >> Subject: [PATCH rtems-tools] bsps/a53_*: Fix typo in qemu options
> >>
> >> ---
> >> tester/rtems/testing/bsps/a53_ilp32_qemu.ini | 2 +-
> tester/rtems/testing/bsps/a53_lp64_qemu.ini | 2 +-
> >> 2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> >> index 6dfc883..3beba06 100644
> >> --- a/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> >> +++ b/tester/rtems/testing/bsps/a53_ilp32_qemu.ini
> >> @@ -35,4 +35,4 @@
> >> bsp = a53_ilp32_qemu
> >> arch = aarch64
> >> tester= %{_rtscripts}/qemu.cfg
> >> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096
> >> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> >> +virt,gic-version=3 -cpu cortex-a53 -m 4096
> >> diff --git a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> >> index f29ab13..1b89284 100644
> >> --- a/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> >> +++ b/tester/rtems/testing/bsps/a53_lp64_qemu.ini
> >> @@ -35,4 +35,4 @@
> >> bsp = a53_lp64_qemu
> >> arch = aarch64
> >> tester= %{_rtscripts}/qemu.cfg
> >> -bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> virt,gic_version=3 -cpu cortex-a53 -m 4096
> >> +bsp_qemu_opts = %{qemu_opts_base} -serial mon:stdio -machine
> >> +virt,gic-version=3 -cpu cortex-a53 -m 4096
> >> --
> >> 2.21.1
> >>
> >> ___
> >> 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
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] config: Initialize task stack alllocator on demand
Hi, How does this effect this documentation ... https://docs.rtems.org/branches/master/c-user/config/task-stack-alloc.html#configure-task-stack-allocator-init ? What drives the demand? Thanks Chris On 13/11/20 8:24 pm, Sebastian Huber wrote: > --- > cpukit/include/rtems/confdefs/wkspace.h | 14 ++ > 1 file changed, 6 insertions(+), 8 deletions(-) > > diff --git a/cpukit/include/rtems/confdefs/wkspace.h > b/cpukit/include/rtems/confdefs/wkspace.h > index d40194cbec..6df3b15ca0 100644 > --- a/cpukit/include/rtems/confdefs/wkspace.h > +++ b/cpukit/include/rtems/confdefs/wkspace.h > @@ -146,8 +146,12 @@ const uintptr_t _Stack_Space_size = > _CONFIGURE_STACK_SPACE_SIZE; >#ifdef CONFIGURE_TASK_STACK_ALLOCATOR_INIT > const Stack_Allocator_initialize _Stack_Allocator_initialize = >CONFIGURE_TASK_STACK_ALLOCATOR_INIT; > - #else > -const Stack_Allocator_initialize _Stack_Allocator_initialize = NULL; > + > +RTEMS_SYSINIT_ITEM( > + _Stack_Allocator_do_initialize, > + RTEMS_SYSINIT_DIRTY_MEMORY, > + RTEMS_SYSINIT_ORDER_MIDDLE > +); >#endif > >const Stack_Allocator_allocate _Stack_Allocator_allocate = > @@ -155,12 +159,6 @@ const uintptr_t _Stack_Space_size = > _CONFIGURE_STACK_SPACE_SIZE; > >const Stack_Allocator_free _Stack_Allocator_free = > CONFIGURE_TASK_STACK_DEALLOCATOR; > - > - RTEMS_SYSINIT_ITEM( > -_Stack_Allocator_do_initialize, > -RTEMS_SYSINIT_DIRTY_MEMORY, > -RTEMS_SYSINIT_ORDER_MIDDLE > - ); > #elif defined(CONFIGURE_TASK_STACK_ALLOCATOR) \ >|| defined(CONFIGURE_TASK_STACK_DEALLOCATOR) >#error "CONFIGURE_TASK_STACK_ALLOCATOR and > CONFIGURE_TASK_STACK_DEALLOCATOR must be both defined or both undefined" > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposal for hardware configuration dependent performance limits
On 14/11/20 11:20 pm, Sebastian Huber wrote: > On 13/11/2020 20:01, Gedare Bloom wrote: > >> On Fri, Nov 13, 2020 at 3:48 AM Sebastian Huber >> wrote: >>> Hello, >>> >>> there is one aspect with respect to performance limits which is >>> currently not considered in this proposal: >>> >>> https://lists.rtems.org/pipermail/devel/2020-November/063213.html >>> >>> You can run the some BSPs such as sparc/gr712rc on several boards. >>> However, each board may have different settings which affect the system >>> performance, for example the CPU frequency, memory controller settings, >>> memory chips, etc. Yes it is common to see this in a number of boards and systems. Another BSP that has this is the Zynq where the same BSP could run on a number of boards however RTEMS does not support runtime configuration and we need separate builds, eg memory size. >>> In the proposal, limits are specified like this: >>> >>> >>> limits: >>> sparc/gr712rc: >>> DirtyCache: >>> max-upper-bound: 0.05 >>> mean-upper-bound: 0.05 >>> FullCache: >>> max-upper-bound: 0.05 >>> mean-upper-bound: 0.05 >>> HotCache: >>> max-upper-bound: 0.05 >>> mean-upper-bound: 0.05 >>> Load/1: >>> max-upper-bound: 0.1 >>> mean-upper-bound: 0.1 >>> Load/2: >>> max-upper-bound: 0.1 >>> mean-upper-bound: 0.1 >>> Load/3: >>> max-upper-bound: 0.1 >>> mean-upper-bound: 0.1 >>> Load/4: >>> max-upper-bound: 0.1 >>> mean-upper-bound: 0.1 >>> >>> This neglects that the limits are subject to a board configuration. One >>> approach to cover this is the addition of a new BSP provided function: >>> >>> const char *rtems_get_hardware_performance_hash(); >>> >>> The BSP feeds all performance related data into a hash function and >> "data" here means configuration? > Yes, hardware configuration. Why not make these values part of the BSP configuration? The defaults for the BSP can have a set of suitable values. Different boards have different configurations to match and a separate kernel build. >>> returns a string encoding (for example a MD5 digest in base64 encoding). >>> The example from above with the performance hash: >>> >>> limits: >>> sparc/gr712rc/XrY7u+Ae7tCTyyK7j1rNww==: >>> DirtyCache: >>> max-upper-bound: 0.05 >>> mean-upper-bound: 0.05 >>> >>> The test suite could report the performance has and a test output analyser >>> coudl check that the reported values are in the specified bounds. >>> >> This will work for fixed sets of configurations. I wonder if it is >> reasonable instead to define ranges over configuration values? Or to >> use board variant mnemonic names instead? How many possible >> configurations are we talking about? >> >> The hash output is fairly opaque, and really small configuration >> changes would result in totally different hashes, so if I change a >> board from 2 MiB RAM to 3 MiB RAM, I might like to know which >> configuration this is closest to in case there is no matching hash. >> >> To invert the hash we will need to keep the table of all the >> configurations mapped to hash values, which is fine I suppose. >> >> I can see that the advantage of a hash is that we don't need to create >> a namespace for configuration options that may influence performance. >> This can give some flexibility for boards that have different sets of >> configuration options that matter. > Maybe we should name it rtems_get_performance_magic_value(). On some BSPs it > might be possible to return something with less entropy, but I think this > stuff > can get very quickly very complicated if you want to use explicit hardware > configuration parameters to approximate expected limits for a new hardware > configuration. The hash is a crude simplification, but it works well for known > hardware configurations. Just using arch/bsp is definitely not enough to > record > performance limits for later regression testing. Magic works by hiding how something works. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 7/8] validation/ts-performance-0: Add test suite
On 13/11/20 9:07 pm, Sebastian Huber wrote:
> Share a default test suite with ts-validation-0.
> ---
> spec/build/testsuites/validation/grp.yml | 2 +
> .../testsuites/validation/performance-0.yml | 19 ++
> testsuites/validation/ts-default.h| 237 ++
> testsuites/validation/ts-performance-0.c | 74 ++
> testsuites/validation/ts-validation-0.c | 155 +---
> 5 files changed, 333 insertions(+), 154 deletions(-)
> create mode 100644 spec/build/testsuites/validation/performance-0.yml
> create mode 100644 testsuites/validation/ts-default.h
> create mode 100644 testsuites/validation/ts-performance-0.c
>
> diff --git a/spec/build/testsuites/validation/grp.yml
> b/spec/build/testsuites/validation/grp.yml
> index 390fb48803..1a903a4198 100644
> --- a/spec/build/testsuites/validation/grp.yml
> +++ b/spec/build/testsuites/validation/grp.yml
> @@ -10,6 +10,8 @@ includes:
> install: []
> ldflags: []
> links:
> +- role: build-dependency
> + uid: performance-0
> - role: build-dependency
>uid: validation-0
> type: build
> diff --git a/spec/build/testsuites/validation/performance-0.yml
> b/spec/build/testsuites/validation/performance-0.yml
> new file mode 100644
> index 00..ba14066dd3
> --- /dev/null
> +++ b/spec/build/testsuites/validation/performance-0.yml
> @@ -0,0 +1,19 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: test-program
> +cflags: []
> +copyrights:
> +- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +features: c cprogram
> +includes: []
> +ldflags: []
> +links: []
> +source:
> +- testsuites/validation/ts-performance-0.c
> +stlib: []
> +target: testsuites/validation/ts-performance-0.exe
> +type: build
> +use-after: []
> +use-before: []
> diff --git a/testsuites/validation/ts-default.h
> b/testsuites/validation/ts-default.h
Who's defaults are these?
> new file mode 100644
> index 00..0f7db65a8e
> --- /dev/null
> +++ b/testsuites/validation/ts-default.h
> @@ -0,0 +1,237 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @brief This header file provides the default validation test suite runner
> + * and application configuration.
> + */
> +
> +/*
> + * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +static char buffer[ 512 ];
> +
> +static const T_action actions[] = {
> + T_report_hash_sha256,
> + T_memory_action,
> + T_check_task_context,
> + T_check_rtems_barriers,
> + T_check_rtems_extensions,
> + T_check_rtems_message_queues,
> + T_check_rtems_partitions,
> + T_check_rtems_periods,
> + T_check_rtems_semaphores,
> + T_check_rtems_tasks,
> + T_check_rtems_timers
> +};
> +
> +static const T_config test_config = {
> + .name = rtems_test_name,
> + .buf = buffer,
> + .buf_size = sizeof( buffer ),
> + .putchar = rtems_put_char,
> + .verbosity = RTEMS_TEST_VERBOSITY,
> + .now = T_now_clock,
> + .allocate = T_memory_allocate,
> + .deallocate = T_memory_deallocate,
> + .action_count = T_ARRAY_SIZE( actions ),
> + .actions = actions
> +};
> +
> +static void runner_task( rtems_task_argument arg )
> +{
> + int exit_code;
> +
> + (void) arg;
> +
> + rtems_test_begin( rtems_test_name, TEST_STATE );
> + T_register();
> + exit_code = T_main( &test_config );
> +
> + if ( exit_code == 0 ) {
> +rtems_test_end( rtems_test_name );
> + }
> +
> + rtems_fatal( RTEMS_FATAL_SOURCE_EXIT,
Re: [PATCH 0/8] Add test suite to validate performance requirements
On 14/11/20 11:13 pm, Sebastian Huber wrote: > On 13/11/2020 20:21, Gedare Bloom wrote: > >> I didn't really raise this in your other threads related to >> performance, but how are we (RTEMS Project) defining performance >> requirements? Are these simply the performance values we get by >> running the tests on our release? Do we aim to hit certain targets and >> reject patches if they don't? Or do we have to debate when a patch >> does change a performance value? Are we going to need to run these >> performance tests as part of regular testing before committing? >> >> I'd like to get some clarity on the idea of performance requirements >> as a community burden before we bake them in to RTEMS. > > Right now we have no systematic indication if there are performance > regressions > or improvements. Which influence have compiler updates, we don't know. I think > for a supposed to be real-time operating system, this is not really good and > we > should step by step improve the situation. One way to do this is to add > performance requirements that state that the runtime of a certain operation > in a > particular environment and system condition should less than or equal to a > certain limit. This limit is obviously hardware dependent. For a start we can > run the performance tests and record the data in the specification data. In a > later test run we can check the values and notice if there are some changes in > the wrong direction. The new test framework was specifically written to get > this > data easily. See for example (1.5 Test Suite - ClockTick): > > https://ftp.rtems.org/pub/rtems/people/sebh/test-report.pdf > > Not every target is suitable to get stable performance data (Qemu is really > bad > at this). I think the SIS (or other GDB simulators) would be a good candidate > to > do this on a regular basis. > > What can we do with the data? It can give some aid to judge changes. > Yes but we need to be cautious. Knowing what changes is good. How we use that data is hard. For example compiler backends vary and evolve at different rates so does a performance regression on an architecture effect updating the compiler if others architectures benefit? There are many questions like this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] config: Initialize task stack alllocator on demand
On 15/11/2020 22:51, Chris Johns wrote: How does this effect this documentation ... https://docs.rtems.org/branches/master/c-user/config/task-stack-alloc.html#configure-task-stack-allocator-init ? No, the allocator initialization handler is documented as optional. However, I missed that _Stack_Allocator_do_initialize() does some checks that could result in fatal errors. I will move these checks to confdefs.h. What drives the demand? It is just something I noticed while looking at this stuff. -- embedded brains GmbH 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 PGP: Public key available on request. embedded brains GmbH 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: Proposal for hardware configuration dependent performance limits
On 16/11/2020 00:33, Chris Johns wrote: In the proposal, limits are specified like this: limits: sparc/gr712rc: DirtyCache: max-upper-bound: 0.05 mean-upper-bound: 0.05 FullCache: max-upper-bound: 0.05 mean-upper-bound: 0.05 HotCache: max-upper-bound: 0.05 mean-upper-bound: 0.05 Load/1: max-upper-bound: 0.1 mean-upper-bound: 0.1 Load/2: max-upper-bound: 0.1 mean-upper-bound: 0.1 Load/3: max-upper-bound: 0.1 mean-upper-bound: 0.1 Load/4: max-upper-bound: 0.1 mean-upper-bound: 0.1 This neglects that the limits are subject to a board configuration. One approach to cover this is the addition of a new BSP provided function: const char *rtems_get_hardware_performance_hash(); The BSP feeds all performance related data into a hash function and "data" here means configuration? Yes, hardware configuration. Why not make these values part of the BSP configuration? The defaults for the BSP can have a set of suitable values. Different boards have different configurations to match and a separate kernel build. This doesn't work on BSPs which support configuration via a hardware enumeration, boot loader settings, or device trees. Also changes in the BSP options have no influence on the BSP name. Not only BSP configuration influence performance, the CPU options play a role too, for example RTEMS_SMP. In order to compare performance values over time we have to obtain the values under the same conditions. -- embedded brains GmbH 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 PGP: Public key available on request. embedded brains GmbH 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 7/8] validation/ts-performance-0: Add test suite
On 16/11/2020 00:53, Chris Johns wrote:
On 13/11/20 9:07 pm, Sebastian Huber wrote:
Share a default test suite with ts-validation-0.
---
spec/build/testsuites/validation/grp.yml | 2 +
.../testsuites/validation/performance-0.yml | 19 ++
testsuites/validation/ts-default.h| 237 ++
testsuites/validation/ts-performance-0.c | 74 ++
testsuites/validation/ts-validation-0.c | 155 +---
5 files changed, 333 insertions(+), 154 deletions(-)
create mode 100644 spec/build/testsuites/validation/performance-0.yml
create mode 100644 testsuites/validation/ts-default.h
create mode 100644 testsuites/validation/ts-performance-0.c
diff --git a/spec/build/testsuites/validation/grp.yml
b/spec/build/testsuites/validation/grp.yml
index 390fb48803..1a903a4198 100644
--- a/spec/build/testsuites/validation/grp.yml
+++ b/spec/build/testsuites/validation/grp.yml
@@ -10,6 +10,8 @@ includes:
install: []
ldflags: []
links:
+- role: build-dependency
+ uid: performance-0
- role: build-dependency
uid: validation-0
type: build
diff --git a/spec/build/testsuites/validation/performance-0.yml
b/spec/build/testsuites/validation/performance-0.yml
new file mode 100644
index 00..ba14066dd3
--- /dev/null
+++ b/spec/build/testsuites/validation/performance-0.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/validation/ts-performance-0.c
+stlib: []
+target: testsuites/validation/ts-performance-0.exe
+type: build
+use-after: []
+use-before: []
diff --git a/testsuites/validation/ts-default.h
b/testsuites/validation/ts-default.h
Who's defaults are these?
This is an implementation of the default validation test suite runner
and application configuration. The goal is to use it for a wide range of
test cases.
new file mode 100644
index 00..0f7db65a8e
--- /dev/null
+++ b/testsuites/validation/ts-default.h
@@ -0,0 +1,237 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @brief This header file provides the default validation test suite runner
+ * and application configuration.
+ */
[...]
+#define CONFIGURE_SCHEDULER_EDF_SMP
+
+#include
+
+RTEMS_SCHEDULER_EDF_SMP(a);
+
+RTEMS_SCHEDULER_EDF_SMP(b);
+
+RTEMS_SCHEDULER_EDF_SMP(c);
+
+#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
+ RTEMS_SCHEDULER_TABLE_EDF_SMP(a, rtems_build_name('A', ' ', ' ', ' ')), \
+ RTEMS_SCHEDULER_TABLE_EDF_SMP(b, rtems_build_name('B', ' ', ' ', ' ')), \
+ RTEMS_SCHEDULER_TABLE_EDF_SMP(c, rtems_build_name('C', ' ', ' ', ' '))
+
+#define CONFIGURE_SCHEDULER_ASSIGNMENTS \
+ RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), \
+ RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
+ RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
+ RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
+
These seems specific but I ma not sure.
This configuration provides enough resources to run a wide range of test
cases. For example, the SMP scheduler configuration with three
schedulers can be used to test most of the SMP support of RTEMS.
Do tests depend on this configuration?
Yes, if the configuration provides the necessary resources, they pass,
otherwise they fail.
Does the number of cores available effect this or the dependent tests? I assume
this is included in a number of tests.
If a test needs three processors and a board has only two, then the test
case should fail.
--
embedded brains GmbH
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
PGP: Public key available on request.
embedded brains GmbH
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
