A.2.1 Summary of Configuration #1: i.MX RT1050 Configuration—Hardware and Software

• • Development board: MIMXRT1050-EVK
  • • Processor: MIMXRT1052DVL6A Arm® Cortex®-M7 core
  • • Number of cores: 1
  • • Core frequency: 600 MHz
  • • Board schematic: SCH-29538 REV A1
• • OS name: Zephyr OS 1.11.99
  • • OS type: real-time
  • • Zephyr OS web page

The second configuration analyzed in the study is a combination of the NXP i.MX 6UL hardware with the Linux operating system. The i.MX6 UltraLight is a high-performance and efficient processor family featuring an ARM A7 core operating at speeds up to 696 MHz at the time of writing. The i.MX6 UltraLite applications processor includes an integrated power management module that reduces the complexity of the external power supply and simplifies power sequencing. Each processor in this family provides various memory interfaces, including 16-bit LPDDR2, DDR3, DDR3L, raw and managed NAND flash, NOR flash, eMMC, Quad SPI, and a wide range of other interfaces for connecting peripherals, such as WLAN, Bluetooth™, GPS, displays, and camera sensors. The software running on the i.MX6 UL is Linux Board Support Package release Linux BSP - kernel 4.9.88-imx_4.9.88_2.0.0_ga. As discussed in greater detail later, unlike the Zephyr™ OS of the first configuration, this is not a real-time variant of Linux.

A.2.2 Summary of Configuration # 2: i.MX 6UL Configuration

• • Development board: MCIMX6G2CVM05AB
  • • Processor: i.MX6UL: i.MX 6UltraLite Processor, based on Arm Cortex-A7 core
  • • Number of cores: 1
  • • Core frequency: 528 MHz
  • • Board schematic: SCH-29163 REV A2
• • OS name: Linux BSP - kernel 4.9.88-imx_4.9.88_2.0.0_ga
  • • OS type: nonreal-time

A.3.1 Microbenchmark #1: Dynamic Memory (Heap) Allocation and Deallocation Benchmark

In C programming language, dynamic memory allocation refers to performing manual memory management via a group of functions in the C standard library. The C programming language manages memory statically, automatically, or dynamically.

Static variables are allocated in main memory, along with the executable code, and persist for the lifetime of the program. The automatically managed variables or local variables are allocated on the stack and they come and go as functions are called and as functions exit. The size of the memory allocation for the static and local variables is defined at the compile-time, except for variable-length arrays. If the required size is not known until runtime (e.g., if data of arbitrary size is being read from the user or from a disk file), then using fixed-size data objects is inadequate. In this situation, dynamic memoryallocation solves the problem—memory is more explicitly managed, typically by allocating it in large regions of free spacecalled heap (Fig. 1).

In other words, heap is a memory region of the computer which is managed manually by the programmer (in the case of C language). In other programming languages, for example, Java, memory is managed automatically.

To manage heap memory location in C under Linux, the malloc () and free ()functions are used (there are also new ()and delete ()functions on C ++). The mallocfunction is used for allocating a space into this memory, and freeis used to deallocate it. In the case of the Zephyr™ OS these functions are named k_malloc() and k_free(), which do the same thing as malloc() and free(). For this analysis, the microbenchmark was developed around these functions and was named heap_bench. The purpose was to measure the time for allocating and deallocating heap memory. Behind the scenes, the benchmark allocates 4 bytes (sizeof(int)) for 1000 iterations of the heap allocation loop, and then deallocates the same allocated memory via the second “heap deallocation” loop. For the Linux BSP, each loop of allocation and deallocation time was measured using a time_get_time (),which is a wrapper function on top of clock_get_time (). For the Zephyr™ OS, the TIMING_INFO_PRE_READ ()function was used.

• ...
• //Linux BSP – heap allocation //
• for (i = 0; i < ITERATIONS; i ++) {
•     time_get_time(&start);
•     pointer[i]= malloc(sizeof(int));
•     *pointer[i] = 0xdeadbeef;
•     time_get_time(&stop);
•     diff = time_get_diff(&stop, &start);
•     total += diff;
• }
• printf("Only call time function: %.lf ns ", (total) / (double) ITERATIONS);
• ...

• ...
• //Linux BSP – heap deallocation //
• for (i = 0; i < ITERATIONS; i ++) {
•     time_get_time(&start);
•     free(pointer[i]);
•     time_get_time(&stop);
•     diff = time_get_diff(&stop, &start);
•     total += diff;
•  }
• printf("Average heap free time: %.lf ns ", (total) / (double)ITERATIONS);
• ...

• ...
• // Zephyr OS – heap allocation //
• for (i = 0; i < ITERATIONS; i ++) {
•     TIMING_INFO_PRE_READ();
•     heap_malloc_start_time = TIMING_INFO_OS_GET_TIME();
•     pointer[i]= k_malloc(sizeof(int));
•     *pointer[i] = 0xdeadbeef;
•     TIMING_INFO_PRE_READ();
•     heap_malloc_end_time = TIMING_INFO_OS_GET_TIME();
• ...

• ...
• //Zephyr OS – heap deallocation//
• for (i = 0; i < ITERATIONS; i ++) {
  
•     TIMING_INFO_PRE_READ();
•     heap_free_start_time = TIMING_INFO_OS_GET_TIME();
•     k_free(pointer[i]);
•     TIMING_INFO_PRE_READ();
•     heap_free_end_time = TIMING_INFO_OS_GET_TIME();
• ...

At the end of the heap allocation and heap deallocation loops, the final average allocation and deallocation times were calculated for a given loop, as can be seen in the source code above.

A.3.2 Microbenchmark #2: Thread Creation and Joining Benchmark

In computer science, a thread of execution is a small sequence of programmed instructions that can be managed independently by a scheduler, the scheduler being part of the operating system in this context. The implementation of threads and processes differ between operating systems, but in most cases a thread is a component of a process. Multiple threads can exist within one process, executing concurrently and sharing resources, like memory, across threads, while different processes do not share these resources. In particular, the threads of a process share its executable code and the values of its variables at any given time.⁸ Fig. 2 depicts two processes, each one having one or multiple threads.

In this comparison, the process is the running benchmark, named thread_bench, which spawns multiple threads using the pthread_create ()POSIX function. It creates 2000 threads and measures the time of creation for all 2000 threads. At the end of thread creation, the time recorded is divided by the number of threads created, giving the average time to create a thread.

• ...
• for (i = 0; i < ITERATIONS; i ++) {
•     if (pthread_attr_init(&attr[i]) != 0) {
•     fprintf(stderr, "pthread_attr_init! ");
•     exit(EXIT_FAILURE);
•     }
  
•     if (posix_memalign(&stacks[i], sysconf(_SC_PAGESIZE), MAX_STACK_SIZE) != 0) {
•     fprintf(stderr, "Failed to allocate aligned memory ");
•     exit(EXIT_FAILURE);
•     }
  
•     if (pthread_attr_setstack(&attr[i], stacks[i], MAX_STACK_SIZE) != 0) {
•     fprintf(stderr, "Failed pthread_attr_setstack! ");
•     exit(EXIT_FAILURE);
•     }
  
•     time_get_time(&start);
•     if (pthread_create(&threads[i], &attr[i], test_function, NULL) != 0) {
•     fprintf(stderr, "Failed to create thread! ");
•     exit(EXIT_FAILURE);
•     }
•     time_get_time(&stop);
• #ifdef DEBUG
•     fprintf(stdout, "Created thread_id %d ", i);
• #endif
•     diff = time_get_diff(&stop, &start);
•     total += diff;
• }
• fprintf(stdout, "Average pthread_create time: %.lf ns ", (total/(double)ITERATIONS));
• ...

This benchmark also measures join time using the pthread_join () function, which synchronizes the parent thread by pausing its execution, until the child thread terminates.

• ...
• for (i = 0; i < ITERATIONS; i ++) {
•     if (threads[i]) {
  
•     time_get_time(&start);
•     if (pthread_join(threads[i], NULL) < 0) {
•     fprintf(stdout, "Failed to join thread ");
•     exit(EXIT_FAILURE);
•     }
•     time_get_time(&stop);
•     diff = time_get_diff(&stop, &start);
•     total += diff;
  
• #ifdef DEBUG
•     fprintf(stdout, "thread %d, joined ", i);
• #endif
•     }
•     }
•     fprintf(stdout, "Average pthread_join time: %.lf ns ",(total/(double)ITERATIONS));
• ...

A.3.3 Microbenchmark #3: Mutex Lock and Unlock Benchmark

In computer science, mutual exclusion is a concurrency control method dedicated to prevent race conditions between two, or multiple, threads. A race condition is a behavior of a system where two independent workflows are modifying in a shared resource, which is used to generate the output of the system. Making an analogy to the real world, we can consider two mechanics (two threads) who are jointly assembling a car engine. They assemble the engine in parallel, however, some of the subcomponents must be assembled in some specific order to ensure that the engine will work properly. Each mechanic has their own part of the engine to assemble. To be sure that components are mounted in the correct order, each mechanic should have exclusive ownership to the relevant portion of the engine during the critical sections of assembly. This exclusive ownership could be associated with the mutex lock, where mutex is our car engine. Freeing the engine could be associated with mutex unlock.

The mutex lock and unlock benchmark, named mutex_bench, measures the time of these two actions 1000 times. At the end, it calculates the average time for locking and unlocking a mutex variable. To execute mutex lock and unlock, we used the pthread_mutex_lock () and pthread_mutex_unlock ()functions of the Pthread API library. Below are some code samples of the benchmark which measures lock and unlock timings.

• ...
• //Linux BSP//
• for (i = 0; i < nr_iterations; i ++) {
•     time_get_time(&start);
•     pthread_mutex_lock(&lock);
•     time_get_time(&stop);
•     delta = time_get_diff(&stop, &start);
•     total_lock += delta;
•     time_get_time(&start);
•     pthread_mutex_unlock(&lock);
•     time_get_time(&stop);
•     delta = time_get_diff(&stop, &start);
•     total_unlock += delta;
• }
•     fprintf(stdout, "Average time for locking a mutex: %.8f ns ",
•     (double) total_lock/ (double) nr_iterations);
•     fprintf(stdout, "Average time for unlocking a mutex: %.8f ns ",
•     (double) total_unlock/ (double) nr_iterations);
• ...

• ...
• //Zephyr OS//
• for (i = 0; i < nr_iterations; i ++) {
•     TIMING_INFO_PRE_READ();
•     mutex_lock_start_time = TIMING_INFO_OS_GET_TIME();
•     pthread_mutex_lock(&lock);
•     TIMING_INFO_PRE_READ();
•     mutex_lock_end_time = TIMING_INFO_OS_GET_TIME();
•     total_lock +=  (mutex_lock_end_time -mutex_lock_start_time);
•     TIMING_INFO_PRE_READ();
•     mutex_unlock_start_time = TIMING_INFO_OS_GET_TIME();
•     pthread_mutex_unlock(&lock);
•     TIMING_INFO_PRE_READ();
•     mutex_unlock_end_time = TIMING_INFO_OS_GET_TIME();
•     total_unlock +=  (mutex_unlock_end_time -
•     mutex_unlock_start_time);
• ...

A.3.4 Microbenchmark #4: Context Switching Benchmark

In computing, a context switch is the process of storing the state of a process of a thread, so that it can be restored and then resume execution from the same point later. This allows multiple processes to share a single CPU and is an essential feature of a multitasking operating system.

The precise meaning of the phrase “context switch” varies significantly in usage. In a multitasking context, it refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an interrupt, such as when a task needs to access disk storage, freeing up CPU time for other tasks. Some operating systems also require a context switch to move between user-mode and kernel-mode tasks. The process of context switching can have a negative impact on system performance, although the size of this effect depends on the nature of the switch being performed (Fig. 3).⁹

This benchmark measures the context switch time by creating two threads, which are continuously context switched 500,000 times. During context switch time, the benchmark records elapsed time which is then divided by the number of context switches to generate the average time for a context switch.