[PATCH] config: Initialize task stack alllocator on demand
--- 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" -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] eng: Add performance specification items
Add items to specify runtime performance requirements. Update #3715. --- You find an updated document here: https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf eng/req/items.rst | 616 +- 1 file changed, 503 insertions(+), 113 deletions(-) diff --git a/eng/req/items.rst b/eng/req/items.rst index 9d3822b..e811213 100644 --- a/eng/req/items.rst +++ b/eng/req/items.rst @@ -109,8 +109,14 @@ The specification item types have the following hierarchy: * :ref:`SpecTypeNonFunctionalRequirementItemType` + * :ref:`SpecTypeGenericNonFunctionalRequirementItemType` + + * :ref:`SpecTypeRuntimePerformanceRequirementItemType` + * :ref:`SpecTypeRequirementValidationItemType` + * :ref:`SpecTypeRuntimeMeasurementTestItemType` + * :ref:`SpecTypeSpecificationItemType` * :ref:`SpecTypeTestCaseItemType` @@ -183,6 +189,8 @@ This type is refined by the following types: * :ref:`SpecTypeRequirementValidationItemType` +* :ref:`SpecTypeRuntimeMeasurementTestItemType` + * :ref:`SpecTypeSpecificationItemType` * :ref:`SpecTypeTestCaseItemType` @@ -1729,8 +1737,8 @@ test-cleanup action loop body after the test post-condition checks. test-context -The attribute value shall be a list. Each list element shall be an -:ref:`SpecTypeActionRequirementTestContextMember`. +The attribute value shall be a list. Each list element shall be a +:ref:`SpecTypeTestContextMember`. test-context-support The attribute value shall be an optional string. If the value is present, @@ -1758,12 +1766,10 @@ test-prepare the test action loop body before the test pre-condition preparations. test-setup -The attribute value shall be an -:ref:`SpecTypeActionRequirementTestFixtureMethod`. +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. test-stop -The attribute value shall be an -:ref:`SpecTypeActionRequirementTestFixtureMethod`. +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. test-support The attribute value shall be an optional string. If the value is present, @@ -1775,8 +1781,7 @@ test-target generated test case source file. test-teardown -The attribute value shall be an -:ref:`SpecTypeActionRequirementTestFixtureMethod`. +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. transition-map The attribute value shall be a list. Each list element shall be an @@ -1943,8 +1948,213 @@ attributes specifies a non-functional requirement. All explicit attributes shall be specified. The explicit attributes for this type are: non-functional-type -The attribute value shall be a :ref:`SpecTypeRequirementNonFunctionalType`. -It shall be the non-functional type of the requirement. +The attribute value shall be a :ref:`SpecTypeName`. It shall be the +non-functional type of the requirement. + +This type is refined by the following types: + +* :ref:`SpecTypeGenericNonFunctionalRequirementItemType` + +* :ref:`SpecTypeRuntimePerformanceRequirementItemType` + +.. _SpecTypeGenericNonFunctionalRequirementItemType: + +Generic Non-Functional Requirement Item Type + + +This type refines the following types: + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``build-configuration`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``constraint`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``design`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``documentation`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``interface`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``interface-requirement`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``maintainability`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``performance`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``portability`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``quality`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``reliability`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is ``resource`` + +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the + ``non-functional-type`` attribute if the value is
[PATCH 1/8] libtest: Make test case allocator configurable
---
cpukit/Makefile.am | 1 -
cpukit/include/rtems/test.h| 2 +
cpukit/libtest/t-test-malloc.c | 112 -
cpukit/libtest/t-test.c| 86 ++
cpukit/libtest/testrun.c | 4 ++
spec/build/cpukit/librtemstest.yml | 1 -
testsuites/libtests/ttest01/init.c | 3 +
7 files changed, 95 insertions(+), 114 deletions(-)
delete mode 100644 cpukit/libtest/t-test-malloc.c
diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 4e370ae639..8c7f9c1ed4 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1877,7 +1877,6 @@ librtemstest_a_SOURCES += libtest/t-test-checks-eno.c
librtemstest_a_SOURCES += libtest/t-test-checks-psx.c
librtemstest_a_SOURCES += libtest/t-test-hash-sha256.c
librtemstest_a_SOURCES += libtest/t-test-interrupt.c
-librtemstest_a_SOURCES += libtest/t-test-malloc.c
librtemstest_a_SOURCES += libtest/t-test-rtems.c
librtemstest_a_SOURCES += libtest/t-test-rtems-context.c
librtemstest_a_SOURCES += libtest/t-test-rtems-fds.c
diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 935e796bf0..7d8b131286 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2286,6 +2286,8 @@ typedef struct {
void *putchar_arg;
T_verbosity verbosity;
T_time (*now)(void);
+ void *(*allocate)(size_t);
+ void (*deallocate)(void *);
size_t action_count;
const T_action *actions;
} T_config;
diff --git a/cpukit/libtest/t-test-malloc.c b/cpukit/libtest/t-test-malloc.c
deleted file mode 100644
index 369bff9a57..00
--- a/cpukit/libtest/t-test-malloc.c
+++ /dev/null
@@ -1,112 +0,0 @@
-/*
- * SPDX-License-Identifier: BSD-2-Clause
- *
- * Copyright (C) 2018 embedded brains GmbH
- *
- * 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
-
-#ifdef __BIGGEST_ALIGNMENT__
-#define T_BIGGEST_ALIGNMENT __BIGGEST_ALIGNMENT__
-#else
-#define T_BIGGEST_ALIGNMENT sizeof(long long)
-#endif
-
-typedef struct __attribute__((__aligned__(T_BIGGEST_ALIGNMENT))) {
- T_destructor base;
- void (*destroy)(void *);
-} T_malloc_destructor;
-
-static void
-T_malloc_destroy(T_destructor *base)
-{
- T_malloc_destructor *dtor;
-
- dtor = (T_malloc_destructor *)(uintptr_t)base;
-
- if (dtor->destroy != NULL) {
- (*dtor->destroy)(dtor + 1);
- }
-
- free(dtor);
-}
-
-static void *
-T_do_malloc(size_t size, void (*destroy)(void *))
-{
- T_malloc_destructor *dtor;
- size_t new_size;
-
- new_size = sizeof(*dtor) + size;
- if (new_size <= size) {
- return NULL;
- }
-
- dtor = malloc(new_size);
- if (dtor != NULL) {
- dtor->destroy = destroy;
- T_add_destructor(&dtor->base, T_malloc_destroy);
- ++dtor;
- }
-
- return dtor;
-}
-
-void *
-T_malloc(size_t size)
-{
- return T_do_malloc(size, NULL);
-}
-
-void *
-T_calloc(size_t nelem, size_t elsize)
-{
- return T_zalloc(nelem * elsize, NULL);
-}
-
-void *
-T_zalloc(size_t size, void (*destroy)(void *))
-{
- void *p;
-
- p = T_do_malloc(size, destroy);
- if (p != NULL) {
- p = memset(p, 0, size);
- }
-
- return p;
-}
-
-void
-T_free(void *ptr)
-{
- T_malloc_destructor *dtor;
-
- dtor = ptr;
- --dtor;
- T_remove_destructor(&dtor->base);
- free(dtor);
-}
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 11f1cf70e9..2e27e3c9e6 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -1299,3 +1299,89 @@ T_get_scope(const char * const * const *desc, char *bu
[PATCH 7/8] validation/ts-performance-0: Add test suite
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
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, (uint32_t) exit_code );
+}
+
+#define MAX_TLS_SIZE RTEMS_ALIGN_UP( 64, RTEMS_TASK_STORAGE_ALIGNMENT )
+
+#define ATTRIBUTES RTEMS_FLOATING_POINT
+
+#define TASK_STORAGE_SIZE \
+ RTEMS_TASK_STORAGE_SIZE( \
+MAX_TLS_SIZE + RTEMS_MINIMUM_STACK_SIZE, \
+ATTRIBUTES \
+ )
+
+#define MAX_TASKS 32
+
+RTEMS_ALIGNED( RTEMS_TASK_STORAGE_ALIGNMENT )
+static char runner_
[PATCH 3/8] libtest: Add primitive test case memory allocator
This primitive test case memory allocator uses memory from the low-level
memory information provided by the BSP. At the beginning of each test
case, the memory available to the test case is reinitialized. This
allows the use of a simple allocate only allocator.
---
cpukit/include/rtems/test.h | 6 ++
cpukit/libtest/t-test-rtems-memory.c | 86
spec/build/cpukit/librtemstest.yml | 1 +
3 files changed, 93 insertions(+)
create mode 100644 cpukit/libtest/t-test-rtems-memory.c
diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 7d8b131286..ae81aac4d0 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2463,6 +2463,12 @@ void T_report_hash_sha256(T_event, const char *);
void T_check_heap(T_event, const char *);
#ifdef __rtems__
+void T_memory_action(T_event, const char *);
+
+void *T_memory_allocate(size_t);
+
+void T_memory_deallocate(void *);
+
void T_check_task_context(T_event, const char *);
void T_check_file_descriptors(T_event, const char *);
diff --git a/cpukit/libtest/t-test-rtems-memory.c
b/cpukit/libtest/t-test-rtems-memory.c
new file mode 100644
index 00..92d21a7ccd
--- /dev/null
+++ b/cpukit/libtest/t-test-rtems-memory.c
@@ -0,0 +1,86 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH
+ *
+ * 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
+
+static Memory_Area T_memory_areas[1];
+
+static Memory_Information T_memory_information =
+MEMORY_INFORMATION_INITIALIZER(T_memory_areas);
+
+static void
+T_memory_initialize(void)
+{
+ const Memory_Information *mem;
+ Memory_Area *area;
+ void *begin;
+ uintptr_t size;
+
+ mem = _Memory_Get();
+ area = _Memory_Get_area(mem, 0);
+ begin = _Memory_Get_free_begin(area);
+ size = _Memory_Get_free_size(area) / 2;
+ _Memory_Consume(area, size);
+ _Memory_Initialize_by_size(&T_memory_areas[0], begin, size);
+}
+
+RTEMS_SYSINIT_ITEM(T_memory_initialize, RTEMS_SYSINIT_WORKSPACE,
+RTEMS_SYSINIT_ORDER_FIRST);
+
+void *
+T_memory_allocate(size_t size)
+{
+ return _Memory_Allocate(&T_memory_information, size,
+ CPU_HEAP_ALIGNMENT);
+}
+
+void
+T_memory_deallocate(void *ptr)
+{
+ (void)ptr;
+}
+
+void
+T_memory_action(T_event event, const char *name)
+{
+ Memory_Area *area;
+
+ (void)name;
+
+ switch (event) {
+ case T_EVENT_CASE_BEGIN:
+ area = &T_memory_areas[0];
+ _Memory_Set_free_begin(area,
+ RTEMS_DECONST(void *, _Memory_Get_begin(area)));
+ break;
+ default:
+ break;
+ };
+}
diff --git a/spec/build/cpukit/librtemstest.yml
b/spec/build/cpukit/librtemstest.yml
index ee116fba49..ae5ffeeb9b 100644
--- a/spec/build/cpukit/librtemstest.yml
+++ b/spec/build/cpukit/librtemstest.yml
@@ -30,6 +30,7 @@ source:
- cpukit/libtest/t-test-rtems-fds.c
- cpukit/libtest/t-test-rtems-heap.c
- cpukit/libtest/t-test-rtems-measure.c
+- cpukit/libtest/t-test-rtems-memory.c
- cpukit/libtest/t-test-rtems-posix-keys.c
- cpukit/libtest/t-test-rtems-objs.c
- cpukit/libtest/t-test-time.c
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/8] Add test suite to validate performance requirements
This patch set introduces a test suite for runtimer performance
validation tests and a test case for the Partition Manager.
Sebastian Huber (8):
libtest: Make test case allocator configurable
libtest: Simplify runtime measurement support
libtest: Add primitive test case memory allocator
libtest: Rename ValidCache in FullCache
libtest: Allow assert checks during test begin
libtest: Simplify "Load" environment reporting
validation/ts-performance-0: Add test suite
validation/ts-performance-0: Add partition tests
cpukit/Makefile.am| 1 -
cpukit/include/rtems/test.h | 12 +-
cpukit/libtest/t-test-rtems-measure.c | 93 ++--
...{t-test-malloc.c => t-test-rtems-memory.c} | 110 ++---
cpukit/libtest/t-test.c | 115 -
cpukit/libtest/testrun.c | 4 +
spec/build/cpukit/librtemstest.yml| 2 +-
spec/build/testsuites/validation/grp.yml | 2 +
.../testsuites/validation/performance-0.yml | 20 +
testsuites/libtests/ttest01/init.c| 3 +
testsuites/validation/tc-part-performance.c | 437 ++
testsuites/validation/ts-default.h| 237 ++
testsuites/validation/ts-performance-0.c | 74 +++
testsuites/validation/ts-validation-0.c | 155 +--
14 files changed, 973 insertions(+), 292 deletions(-)
rename cpukit/libtest/{t-test-malloc.c => t-test-rtems-memory.c} (51%)
create mode 100644 spec/build/testsuites/validation/performance-0.yml
create mode 100644 testsuites/validation/tc-part-performance.c
create mode 100644 testsuites/validation/ts-default.h
create mode 100644 testsuites/validation/ts-performance-0.c
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 4/8] libtest: Rename ValidCache in FullCache
This name better reflects the execution envirnoment in which the cache
is fully loaded with valid data unrelated to the body request handler.
---
cpukit/include/rtems/test.h | 2 +-
cpukit/libtest/t-test-rtems-measure.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index ae81aac4d0..509c7d0213 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2557,7 +2557,7 @@ typedef struct {
#define T_MEASURE_RUNTIME_REPORT_SAMPLES 0x2
-#define T_MEASURE_RUNTIME_DISABLE_VALID_CACHE 0x10
+#define T_MEASURE_RUNTIME_DISABLE_FULL_CACHE 0x10
#define T_MEASURE_RUNTIME_DISABLE_HOT_CACHE 0x20
diff --git a/cpukit/libtest/t-test-rtems-measure.c
b/cpukit/libtest/t-test-rtems-measure.c
index ea3f0ab3e2..0607312701 100644
--- a/cpukit/libtest/t-test-rtems-measure.c
+++ b/cpukit/libtest/t-test-rtems-measure.c
@@ -478,7 +478,7 @@ get_maximum_retries(const T_measure_runtime_request *req)
}
static void
-measure_valid_cache(T_measure_runtime_context *ctx,
+measure_full_cache(T_measure_runtime_context *ctx,
const T_measure_runtime_request *req)
{
size_t sample_count;
@@ -488,7 +488,7 @@ measure_valid_cache(T_measure_runtime_context *ctx,
size_t i;
T_time begin;
- measure_variant_begin(req->name, "ValidCache");
+ measure_variant_begin(req->name, "FullCache");
begin = T_now();
sample_count = ctx->sample_count;
samples = ctx->samples;
@@ -803,11 +803,11 @@ T_measure_runtime(T_measure_runtime_context *ctx,
const T_measure_runtime_request *req)
{
/*
-* Do ValidCache variant before HotCache to get a good overall cache
+* Do FullCache variant before HotCache to get a good overall cache
* state for the HotCache variant.
*/
- if ((req->flags & T_MEASURE_RUNTIME_DISABLE_VALID_CACHE) == 0) {
- measure_valid_cache(ctx, req);
+ if ((req->flags & T_MEASURE_RUNTIME_DISABLE_FULL_CACHE) == 0) {
+ measure_full_cache(ctx, req);
}
if ((req->flags & T_MEASURE_RUNTIME_DISABLE_HOT_CACHE) == 0) {
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/8] libtest: Simplify runtime measurement support
Use the test case allocator functions T_zalloc() and T_malloc().
Restore the task affinity of the runner task.
---
cpukit/libtest/t-test-rtems-measure.c | 79 +++
1 file changed, 32 insertions(+), 47 deletions(-)
diff --git a/cpukit/libtest/t-test-rtems-measure.c
b/cpukit/libtest/t-test-rtems-measure.c
index 162aad0e93..ea3f0ab3e2 100644
--- a/cpukit/libtest/t-test-rtems-measure.c
+++ b/cpukit/libtest/t-test-rtems-measure.c
@@ -43,7 +43,6 @@ typedef struct {
} load_context;
struct T_measure_runtime_context {
- T_destructor destructor;
size_t sample_count;
T_ticks *samples;
size_t cache_line_size;
@@ -52,6 +51,9 @@ struct T_measure_runtime_context {
rtems_id runner;
uint32_t load_count;
load_context *load_contexts;
+#ifdef RTEMS_SMP
+ cpu_set_t cpus;
+#endif
};
static unsigned int
@@ -127,34 +129,28 @@ load_worker(rtems_task_argument arg)
}
static void
-destroy_worker(const T_measure_runtime_context *ctx)
+destroy(void *ptr)
{
+ const T_measure_runtime_context *ctx;
uint32_t load;
+ ctx = ptr;
+
for (load = 0; load < ctx->load_count; ++load) {
const load_context *lctx;
lctx = &ctx->load_contexts[load];
- if (lctx->chunk != ctx->chunk) {
- free(RTEMS_DEVOLATILE(unsigned int *, lctx->chunk));
- }
-
if (lctx->id != 0) {
- rtems_task_delete(lctx->id);
+ (void)rtems_task_delete(lctx->id);
}
}
-}
-static void
-destroy(T_destructor *dtor)
-{
- T_measure_runtime_context *ctx;
-
- ctx = (T_measure_runtime_context *)dtor;
- destroy_worker(ctx);
- free(ctx);
+#ifdef RTEMS_SMP
+ (void)rtems_task_set_affinity(RTEMS_SELF, sizeof(ctx->cpus),
+ &ctx->cpus);
+#endif
}
static void *
@@ -166,7 +162,7 @@ add_offset(const volatile void *p, uintptr_t o)
static void *
align_up(const volatile void *p, uintptr_t a)
{
- return (void *)(((uintptr_t)p + a - 1) & ~(a - 1));
+ return (void *)RTEMS_ALIGN_UP((uintptr_t)p, a);
}
T_measure_runtime_context *
@@ -178,7 +174,6 @@ T_measure_runtime_create(const T_measure_runtime_config
*config)
size_t chunk_size;
size_t load_size;
uint32_t load_count;
- bool success;
uint32_t i;
#ifdef RTEMS_SMP
cpu_set_t cpu;
@@ -203,13 +198,21 @@ T_measure_runtime_create(const T_measure_runtime_config
*config)
load_count = rtems_scheduler_get_processor_maximum();
load_size = load_count * sizeof(ctx->load_contexts[0]);
- ctx = malloc(sizeof(*ctx) + sample_size + load_size + chunk_size +
- 2 * cache_line_size);
+ ctx = T_zalloc(sizeof(*ctx) + sample_size + load_size + chunk_size +
+ 2 * cache_line_size, destroy);
if (ctx == NULL) {
return NULL;
}
+#ifdef RTEMS_SMP
+ (void)rtems_task_get_affinity(RTEMS_SELF, sizeof(ctx->cpus),
+ &ctx->cpus);
+ CPU_ZERO(&cpu);
+ CPU_SET(0, &cpu);
+ (void)rtems_task_set_affinity(RTEMS_SELF, sizeof(cpu), &cpu);
+#endif
+
ctx->sample_count = config->sample_count;
ctx->samples = add_offset(ctx, sizeof(*ctx));
ctx->cache_line_size = cache_line_size;
@@ -221,45 +224,39 @@ T_measure_runtime_create(const T_measure_runtime_config
*config)
ctx->samples = align_up(ctx->samples, cache_line_size);
ctx->chunk = align_up(ctx->chunk, cache_line_size);
- memset(ctx->load_contexts, 0, load_size);
- success = true;
-
for (i = 0; i < load_count; ++i) {
rtems_status_code sc;
rtems_id id;
load_context *lctx;
-#ifdef RTEMS_SMP
- rtems_task_priority priority;
+ rtems_task_priority max_prio;
rtems_id scheduler;
sc = rtems_scheduler_ident_by_processor(i, &scheduler);
if (sc != RTEMS_SUCCESSFUL) {
continue;
}
-#endif
+
sc = rtems_task_create(rtems_build_name('L', 'O', 'A', 'D'),
- RTEMS_MAXIMUM_PRIORITY - 1, RTEMS_MINIMUM_STACK_SIZE,
- RTEMS_DEFAULT_MODES, RTEMS_DEFAULT_ATTRIBUTES, &id);
+ 1, RTEMS_MINIMUM_STACK_SIZE, RTEMS_DEFAULT_MODES,
+ RTEMS_DEFAULT_ATTRIBUTES, &id);
if (sc != RTEMS_SUCCESSFUL) {
- success = false;
- break;
+ return NULL;
}
lctx = &ctx->load_contexts[i];
-
lctx->master = ctx;
lctx->id = id;
- lctx->chunk = malloc(chunk_size);
+ lctx->chunk = T_malloc(chunk_size);
if (lctx->chunk == NULL) {
lctx->chunk = ctx->chunk;
}
[PATCH 6/8] libtest: Simplify "Load" environment reporting
Report all runtime measurement environments with a name only and encode
the worker count of the "Load" environment in the name.
Update #3199.
---
cpukit/libtest/t-test-rtems-measure.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/libtest/t-test-rtems-measure.c
b/cpukit/libtest/t-test-rtems-measure.c
index 0607312701..aed309928f 100644
--- a/cpukit/libtest/t-test-rtems-measure.c
+++ b/cpukit/libtest/t-test-rtems-measure.c
@@ -708,8 +708,8 @@ measure_load_variant(T_measure_runtime_context *ctx,
T_time begin;
size_t token;
- measure_variant_begin(req->name, "Load");
- T_printf("M:L:%" PRIu32 "\n", load + 1);
+ T_printf("M:B:%s\n", req->name);
+ T_printf("M:V:Load/%" PRIu32 "\n", load + 1);
begin = T_now();
sample_count = ctx->sample_count;
samples = ctx->samples;
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 5/8] libtest: Allow assert checks during test begin
Allow assert checks in test begin actions and setup fixture methods.
---
cpukit/include/rtems/test.h | 2 +-
cpukit/libtest/t-test.c | 29 +
2 files changed, 18 insertions(+), 13 deletions(-)
diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 509c7d0213..573f7b93c9 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2306,7 +2306,7 @@ void T_run_all(void);
void T_run_by_name(const char *);
-void T_case_begin(const char *, const T_fixture *);
+bool T_case_begin(const char *, const T_fixture *);
void T_case_end(void);
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 2e27e3c9e6..ca91d1592f 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -948,7 +948,7 @@ T_do_run_initialize(const T_config *config)
return ctx;
}
-static void
+static bool
T_do_case_begin(T_context *ctx, const T_case_context *tc)
{
const T_config *config;
@@ -969,16 +969,23 @@ T_do_case_begin(T_context *ctx, const T_case_context *tc)
T_actions_forward(config, T_EVENT_CASE_EARLY, tc->name);
T_do_log(ctx, T_NORMAL, "B:%s\n", tc->name);
ctx->case_begin_time = (*config->now)();
- T_actions_forward(config, T_EVENT_CASE_BEGIN, tc->name);
- if (fixture != NULL) {
- ctx->case_fixture.fixture = fixture;
- ctx->case_fixture.context = fixture->initial_context;
+ if (setjmp(ctx->case_begin_context) == 0) {
+ T_actions_forward(config, T_EVENT_CASE_BEGIN, tc->name);
+
+ if (fixture != NULL) {
+ ctx->case_fixture.fixture = fixture;
+ ctx->case_fixture.context = fixture->initial_context;
- if (fixture->setup != NULL) {
- (*fixture->setup)(ctx->case_fixture.context);
+ if (fixture->setup != NULL) {
+ (*fixture->setup)(ctx->case_fixture.context);
+ }
}
+
+ return true;
}
+
+ return false;
}
static void
@@ -1034,9 +1041,7 @@ T_do_case_end(T_context *ctx, const T_case_context *tc)
static void
T_run_case(T_context *ctx, const T_case_context *tc)
{
- T_do_case_begin(ctx, tc);
-
- if (setjmp(ctx->case_begin_context) == 0) {
+ if (T_do_case_begin(ctx, tc)) {
(*tc->body)();
}
@@ -1140,7 +1145,7 @@ T_run_by_name(const char *name)
static T_case_context default_case;
-void
+bool
T_case_begin(const char *name, const T_fixture *fixture)
{
T_case_context *tc;
@@ -1148,7 +1153,7 @@ T_case_begin(const char *name, const T_fixture *fixture)
tc = &default_case;
tc->name = name;
tc->fixture = fixture;
- T_do_case_begin(&T_instance, tc);
+ return T_do_case_begin(&T_instance, tc);
}
void
--
2.26.2
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 8/8] validation/ts-performance-0: Add partition tests
---
.../testsuites/validation/performance-0.yml | 1 +
testsuites/validation/tc-part-performance.c | 437 ++
2 files changed, 438 insertions(+)
create mode 100644 testsuites/validation/tc-part-performance.c
diff --git a/spec/build/testsuites/validation/performance-0.yml
b/spec/build/testsuites/validation/performance-0.yml
index ba14066dd3..711edb0c75 100644
--- a/spec/build/testsuites/validation/performance-0.yml
+++ b/spec/build/testsuites/validation/performance-0.yml
@@ -11,6 +11,7 @@ includes: []
ldflags: []
links: []
source:
+- testsuites/validation/tc-part-performance.c
- testsuites/validation/ts-performance-0.c
stlib: []
target: testsuites/validation/ts-performance-0.exe
diff --git a/testsuites/validation/tc-part-performance.c
b/testsuites/validation/tc-part-performance.c
new file mode 100644
index 00..46f48c7bf5
--- /dev/null
+++ b/testsuites/validation/tc-part-performance.c
@@ -0,0 +1,437 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestCaseRtemsPartValPerformance
+ */
+
+/*
+ * 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.
+ */
+
+/*
+ * This file is part of the RTEMS quality process and was automatically
+ * generated. If you find something that needs to be fixed or
+ * worded better please post a report or patch to an RTEMS mailing list
+ * or raise a bug report:
+ *
+ * https://docs.rtems.org/branches/master/user/support/bugs.html
+ *
+ * For information on updating and regenerating please refer to:
+ *
+ * https://docs.rtems.org/branches/master/eng/req/howto.html
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+
+#include
+
+/**
+ * @defgroup RTEMSTestCaseRtemsPartValPerformance \
+ * spec:/rtems/part/val/performance
+ *
+ * @ingroup RTEMSTestSuiteTestsuitesPerformance0
+ *
+ * @brief This test case provides a context to run Partition Manager
+ * performance tests.
+ *
+ * @{
+ */
+
+/**
+ * @brief Test context for spec:/rtems/part/val/performance test case.
+ */
+typedef struct {
+ /**
+ * @brief This member provides a partition with exactly one free buffer.
+ */
+ rtems_id part_one;
+
+ /**
+ * @brief This member provides a partition with exactly
+ * ${.:/params/buffer-count} free buffers.
+ */
+ rtems_id part_many;
+
+ /**
+ * @brief This member provides a status code.
+ */
+ rtems_status_code status;
+
+ /**
+ * @brief This member provides a buffer pointer.
+ */
+ void *buffer;
+
+ /**
+ * @brief This member provides a second buffer pointer.
+ */
+ void *buffer_2;
+
+ /**
+ * @brief This member references the measure runtime context.
+ */
+ T_measure_runtime_context *context;
+
+ /**
+ * @brief This member provides the measure runtime request.
+ */
+ T_measure_runtime_request request;
+} RtemsPartValPerformance_Context;
+
+static RtemsPartValPerformance_Context
+ RtemsPartValPerformance_Instance;
+
+static void RtemsPartValPerformance_Setup_Context(
+ RtemsPartValPerformance_Context *ctx
+)
+{
+ T_measure_runtime_config config;
+
+ memset( &config, 0, sizeof( config ) );
+ config.sample_count = 1000;
+ ctx->request.arg = ctx;
+ ctx->context = T_measure_runtime_create( &config );
+ T_assert_not_null( ctx->context );
+}
+
+/**
+ * @brief Creates the test partition.
+ */
+static void RtemsPartValPerformance_Setup(
+ RtemsPartValPerformance_Context *ctx
+)
+{
+ rtems_status_code sc;
+ size_tsize;
+ void *area;
+ uintptr_t length;
+
+ size = sizeof( rtems_chain_node );
+
+ area = T_malloc( size );
+ sc = rtems_partition_create(
+rtems_build_name( ' ', '
Re: [PATCH rtems-libbsd] Update arm64/aarch64 support
Looks good. -- 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 1/2] spec/aarch64: Ensure that libbsd can build properly
On 12/11/2020 14:32, Kinsey Moore wrote:
These files are required for libbsd to build against the AArch64 A53
BSPs.
---
spec/build/bsps/aarch64/grp.yml | 4
1 file changed, 4 insertions(+)
diff --git a/spec/build/bsps/aarch64/grp.yml b/spec/build/bsps/aarch64/grp.yml
index 4b5f998a12..e0a8e607a5 100644
--- a/spec/build/bsps/aarch64/grp.yml
+++ b/spec/build/bsps/aarch64/grp.yml
@@ -5,6 +5,10 @@ copyrights:
enabled-by: true
includes: []
install:
+- destination: ${BSP_INCLUDEDIR}/bsp
+ source:
+ - bsps/arm/include/bsp/linker-symbols.h
+ - bsps/arm/include/bsp/start.h
- destination: ${BSP_INCLUDEDIR}/dev/clock
source:
- bsps/include/dev/clock/arm-generic-timer.h
This is a bit strange. You install files which are not used to build the
BSP?
--
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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32
On 12/11/2020 14:32, Kinsey Moore wrote: The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds was previously present on LP64 builds and causes no issues within RTEMS, but causes relocation/alignment issues when building libbsd. This restricts those alignment changes to ILP32 builds. The SUBALIGN() is currently only used on aarch64 in RTEMS. Why is it necessary? The PowerPC port for example uses a single linkcmds.base for the 32-bit and 64-bit without a SUBALIGN(). -- 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
Proposal for hardware configuration dependent performance limits
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. 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 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. -- 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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32
-Original Message- From: Sebastian Huber Sent: Friday, November 13, 2020 04:26 To: Kinsey Moore ; devel@rtems.org Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32 >On 12/11/2020 14:32, Kinsey Moore wrote: > >> The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds >> was previously present on LP64 builds and causes no issues within >> RTEMS, but causes relocation/alignment issues when building libbsd. >> This restricts those alignment changes to ILP32 builds. >The SUBALIGN() is currently only used on aarch64 in RTEMS. Why is it >necessary? The PowerPC port for example uses a single linkcmds.base for the >32-bit and 64-bit without a SUBALIGN(). The SUBALIGN was necessary because the default alignment was 8 bytes and the ILP32 code would fail during initialization while iterating over the linker sets since the upper half-word of every address was zeroed out and was being treated as another init call. Is there a preferred way to accomplish this that doesn't involve SUBALIGN? Given my experience with AArch64, I would expect the PowerPC linker script to need to do the same though upon review it obviously doesn't. The difference may be due to a bug in the ILP32 portions of the AArch64 toolchain since it's relatively new. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32
On 13/11/2020 15:13, Kinsey Moore wrote: -Original Message- From: Sebastian Huber Sent: Friday, November 13, 2020 04:26 To: Kinsey Moore;devel@rtems.org Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32 On 12/11/2020 14:32, Kinsey Moore wrote: The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds was previously present on LP64 builds and causes no issues within RTEMS, but causes relocation/alignment issues when building libbsd. This restricts those alignment changes to ILP32 builds. The SUBALIGN() is currently only used on aarch64 in RTEMS. Why is it necessary? The PowerPC port for example uses a single linkcmds.base for the 32-bit and 64-bit without a SUBALIGN(). The SUBALIGN was necessary because the default alignment was 8 bytes and the ILP32 code would fail during initialization while iterating over the linker sets since the upper half-word of every address was zeroed out and was being treated as another init call. Is there a preferred way to accomplish this that doesn't involve SUBALIGN? Why can't you remove all the SUBALIGN() from the linker script? For example aarch64-rtems6-ld --verbose | grep SUBALIGN has no output. -- 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 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32
-Original Message- From: Sebastian Huber Sent: Friday, November 13, 2020 08:16 To: Kinsey Moore ; devel@rtems.org Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32 >On 13/11/2020 15:13, Kinsey Moore wrote: > >> -Original Message- >> From: Sebastian Huber >> Sent: Friday, November 13, 2020 04:26 >> To: Kinsey Moore;devel@rtems.org >> Subject: Re: [PATCH 2/2] spec/aarch64: Only apply SUBALIGN(4) to ILP32 >> >>> On 12/11/2020 14:32, Kinsey Moore wrote: >>> The SUBALIGN(4) required on rtemsroset and rtemsrwset for ILP32 builds was previously present on LP64 builds and causes no issues within RTEMS, but causes relocation/alignment issues when building libbsd. This restricts those alignment changes to ILP32 builds. >>> The SUBALIGN() is currently only used on aarch64 in RTEMS. Why is it >>> necessary? The PowerPC port for example uses a single linkcmds.base for the >>> 32-bit and 64-bit without a SUBALIGN(). >> The SUBALIGN was necessary because the default alignment was 8 bytes and the >> ILP32 code would fail during initialization while iterating over the linker >> sets since the upper half-word of every address was zeroed out and was being >> treated as another init call. Is there a preferred way to accomplish this >> that doesn't involve SUBALIGN? > > Why can't you remove all the SUBALIGN() from the linker script? > > For example > > aarch64-rtems6-ld --verbose | grep SUBALIGN > > has no output. That output is specifically for LP64 AArch64. ILP32 linker scripts have different OUTPUT_ARCH and OUTPUT_FORMAT directives. I wasn't able to get aarch64-rtems6-ld to output an ILP32 default linker script. Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: [PATCH 1/2] spec/aarch64: Ensure that libbsd can build properly
-Original Message-
From: Sebastian Huber
Sent: Friday, November 13, 2020 04:23
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH 1/2] spec/aarch64: Ensure that libbsd can build properly
On 12/11/2020 14:32, Kinsey Moore wrote:
>> install:
>> +- destination: ${BSP_INCLUDEDIR}/bsp
>> + source:
>> + - bsps/arm/include/bsp/linker-symbols.h
>> + - bsps/arm/include/bsp/start.h
>> - destination: ${BSP_INCLUDEDIR}/dev/clock
>> source:
>> - bsps/include/dev/clock/arm-generic-timer.h
> This is a bit strange. You install files which are not used to build the BSP?
They are used by bspstart.c and bspstarthooks.c so they're used to build the
BSP, but they're only required for some external applications and libraries
which is why they weren't already being installed. This matches how ARM,
RISC-V, and other BSPs install start.h and linker-symbols.h.
Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Proposal for hardware configuration dependent performance limits
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. 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? > 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. > -- > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] eng: Add performance specification items
On Fri, Nov 13, 2020 at 2:47 AM Sebastian Huber wrote: > > Add items to specify runtime performance requirements. > > Update #3715. > --- > > You find an updated document here: > > https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf > > eng/req/items.rst | 616 +- > 1 file changed, 503 insertions(+), 113 deletions(-) > > diff --git a/eng/req/items.rst b/eng/req/items.rst > index 9d3822b..e811213 100644 > --- a/eng/req/items.rst > +++ b/eng/req/items.rst > @@ -109,8 +109,14 @@ The specification item types have the following > hierarchy: > > * :ref:`SpecTypeNonFunctionalRequirementItemType` > > + * :ref:`SpecTypeGenericNonFunctionalRequirementItemType` > + > + * :ref:`SpecTypeRuntimePerformanceRequirementItemType` > + >* :ref:`SpecTypeRequirementValidationItemType` > > + * :ref:`SpecTypeRuntimeMeasurementTestItemType` > + >* :ref:`SpecTypeSpecificationItemType` > >* :ref:`SpecTypeTestCaseItemType` > @@ -183,6 +189,8 @@ This type is refined by the following types: > > * :ref:`SpecTypeRequirementValidationItemType` > > +* :ref:`SpecTypeRuntimeMeasurementTestItemType` > + > * :ref:`SpecTypeSpecificationItemType` > > * :ref:`SpecTypeTestCaseItemType` > @@ -1729,8 +1737,8 @@ test-cleanup > action loop body after the test post-condition checks. > > test-context > -The attribute value shall be a list. Each list element shall be an > -:ref:`SpecTypeActionRequirementTestContextMember`. > +The attribute value shall be a list. Each list element shall be a > +:ref:`SpecTypeTestContextMember`. > > test-context-support > The attribute value shall be an optional string. If the value is present, > @@ -1758,12 +1766,10 @@ test-prepare > the test action loop body before the test pre-condition preparations. > > test-setup > -The attribute value shall be an > -:ref:`SpecTypeActionRequirementTestFixtureMethod`. > +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. > > test-stop > -The attribute value shall be an > -:ref:`SpecTypeActionRequirementTestFixtureMethod`. > +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. > > test-support > The attribute value shall be an optional string. If the value is present, > @@ -1775,8 +1781,7 @@ test-target > generated test case source file. > > test-teardown > -The attribute value shall be an > -:ref:`SpecTypeActionRequirementTestFixtureMethod`. > +The attribute value shall be a :ref:`SpecTypeTestSupportMethod`. > > transition-map > The attribute value shall be a list. Each list element shall be an > @@ -1943,8 +1948,213 @@ attributes specifies a non-functional requirement. > All explicit attributes > shall be specified. The explicit attributes for this type are: > > non-functional-type > -The attribute value shall be a > :ref:`SpecTypeRequirementNonFunctionalType`. > -It shall be the non-functional type of the requirement. > +The attribute value shall be a :ref:`SpecTypeName`. It shall be the > +non-functional type of the requirement. > + > +This type is refined by the following types: > + > +* :ref:`SpecTypeGenericNonFunctionalRequirementItemType` > + > +* :ref:`SpecTypeRuntimePerformanceRequirementItemType` > + > +.. _SpecTypeGenericNonFunctionalRequirementItemType: > + > +Generic Non-Functional Requirement Item Type > + > + > +This type refines the following types: > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the through? > + ``non-functional-type`` attribute if the value is ``build-configuration`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``constraint`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``design`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``documentation`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``interface`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``interface-requirement`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``maintainability`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``performance`` > + Is there a specific kind of performance (metric) in mind? latency vs throughput? Or does it not matter > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the value is ``portability`` > + > +* :ref:`SpecTypeNonFunctionalRequirementItemType` though the > + ``non-functional-type`` attribute if the v
Re: [PATCH 0/8] Add test suite to validate performance requirements
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.
Gedare
On Fri, Nov 13, 2020 at 3:08 AM Sebastian Huber
wrote:
>
> This patch set introduces a test suite for runtimer performance
> validation tests and a test case for the Partition Manager.
>
> Sebastian Huber (8):
> libtest: Make test case allocator configurable
> libtest: Simplify runtime measurement support
> libtest: Add primitive test case memory allocator
> libtest: Rename ValidCache in FullCache
> libtest: Allow assert checks during test begin
> libtest: Simplify "Load" environment reporting
> validation/ts-performance-0: Add test suite
> validation/ts-performance-0: Add partition tests
>
> cpukit/Makefile.am| 1 -
> cpukit/include/rtems/test.h | 12 +-
> cpukit/libtest/t-test-rtems-measure.c | 93 ++--
> ...{t-test-malloc.c => t-test-rtems-memory.c} | 110 ++---
> cpukit/libtest/t-test.c | 115 -
> cpukit/libtest/testrun.c | 4 +
> spec/build/cpukit/librtemstest.yml| 2 +-
> spec/build/testsuites/validation/grp.yml | 2 +
> .../testsuites/validation/performance-0.yml | 20 +
> testsuites/libtests/ttest01/init.c| 3 +
> testsuites/validation/tc-part-performance.c | 437 ++
> testsuites/validation/ts-default.h| 237 ++
> testsuites/validation/ts-performance-0.c | 74 +++
> testsuites/validation/ts-validation-0.c | 155 +--
> 14 files changed, 973 insertions(+), 292 deletions(-)
> rename cpukit/libtest/{t-test-malloc.c => t-test-rtems-memory.c} (51%)
> create mode 100644 spec/build/testsuites/validation/performance-0.yml
> create mode 100644 testsuites/validation/tc-part-performance.c
> create mode 100644 testsuites/validation/ts-default.h
> create mode 100644 testsuites/validation/ts-performance-0.c
>
> --
> 2.26.2
>
> ___
> 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: Proposal for hardware configuration dependent performance limits
I don't understand this proposal. Is this an approach used somewhere else where I can review how this works? If not I need a clearer explanation. > On Nov 13, 2020, at 14: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. 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? > >> 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. > > >> -- >> 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 > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering. signature.asc Description: Message signed with OpenPGP ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
