RTOS Report

LiTH 2013-06-28

How VxWorks handles process scheduling and memory management in comparison to QNX
Patrik Alnefelt patal533@student.liu.se Marcus Svensson marsv024@student.liu.se

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

INDEX 1. ABSTRACT.........................................................................................................................................................3 2. INTRODUCTION...............................................................................................................................................3 PROCESS SCHEDULING....................................................................................................................................4 2.1. QNX..............................................................................................................................................................4 2.2. VXWORKS......................................................................................................................................................5 2.3. COMPARISON..................................................................................................................................................5 3. MEMORY MANAGEMENT.............................................................................................................................6 3.1. QNX..............................................................................................................................................................6 3.2. VXWORKS......................................................................................................................................................7 3.3. COMPARISON..................................................................................................................................................8 4. CONCLUSION....................................................................................................................................................9

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

1. Abstract
The purpose of this report is to state the differences and similarities between the two real time operative systems QNX and VxWorks in how they handle Process Scheduling and Memory Management. The goal is to get a better understanding of real time operative systems and how they work. The main conclusion we have drawn from the comparison made is that the two systems are equivalent when it comes to system performance and features. The biggest difference between them is how they are implemented.

2. Introduction
In this report we first start looking at Process Scheduling for QNX and then for VxWorks. When the both OS have been presented, a comparison is made between the two stating differences and similarities. The next thing we look at is Memory Management in first QNX and then VxWorks followed by another comparison. In the last chapter we draw conclusions from what previous sections have discussed.

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

Process Scheduling
2.1. QNX1
QNX is a microkernel real-time operating system, from now on referred to as an RTOS. A microkernel RTOS is special in the way that the OS is built up with a number of small services which each handle a specific task, this is basically a set of system calls which is available to the developer. These services only implement low-level communication over network and between processes, process scheduling and interrupt handling. Other OS functions as file-system and device drivers are deployed as user processes outside the kernel. In contrast most other OS use a monolithic kernel. In that case all kernel functions reside in one big program. Using the microkernel design in QNX has resulted in a small code with low complexity. This could for instance be useful when determining how long time system calls can take, or when debugging user code. The perhaps biggest advantage with this approach is that the OS is very scalable. The developer is free to choose exactly what components that should be a part of the RTOS. Each process in QNX consists of one or more threads. When it comes to scheduling QNX schedules threads and not processes. Threads are scheduled globally over the system, which means that they are treated the same no matter what process they belong to. This is also true for thread priority, what process a thread belongs to does not matter. When scheduling threads, the scheduler looks at the priority of all threads in the system. There are 64 levels of priorities that can be assigned to a thread, where 63 is the highest and 0 is the lowest priority. The priority level 0 is a special case, in which the system idle process is placed. Each priority level has its own queue where all processes having that priority are placed. When threads are rescheduled the scheduler selects the thread with the highest priority that is ready to run and gives the CPU to it. This happens whenever a thread changes its status or is pre-empted from the CPU. QNX supports different algorithms for scheduling threads; FIFO, Round Robin and Sporadic scheduling. All threads are scheduled independently which allows different scheduling algorithms to be used on threads in the same system, their priorities and algorithms may also be changed during run-time thread. FIFO (First-In-First-Out) Scheduling is pretty much described by its name. The first thread that is placed in the priority queue is the first one to be selected to run. When Round Robin Scheduling is used, threads are put in its priority queue. The thread that is in the front of the queue is selected to run. The trick here is that each thread is given a time slice for which it may run. If the thread exceeds the given time it is pre-empted and put at the back of the queue again, allowing other threads to run in between. Sporadic scheduling works a bit different. Each thread is assigned a normal priority and a low priority, along with a budget time which represents the time the thread is allowed to run at its normal priority. When the thread has been running at normal priority for the whole duration of its budgeted time, the threads priority is changed to its low priority. When at low priority it may or may not run depending on other threads and their priority. After some time threads using sporadic scheduling get their budgeted time replenished and may resume at normal priority.
1

QNX Software Systems Ltd. (2003), System Architecture guide

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

2.2. VxWorks2
VxWorks is based on a monolithic kernel where all basic features of the OS are placed. In a basic setup of VxWorks a single process is used and both the kernel and tasks are sharing the same address space, which allows very fast context switching resulting in high performance. In most other RTOS threads are used to provide concurrency. VxWorks use tasks, which is almost the same as threads. If a VxWorks setup is without support for processes, then all tasks run in the same address space as the kernel. This allows for fast context switching but puts limits on memory. It is not always desirable that the tasks share memory with the kernel. VxWorks can be run with process support, and then tasks get their own address space which makes them more equal to what a thread is. VxWorks provides a set of different scheduler options, the traditional VxWorks scheduler, POSIX scheduler or a custom scheduler. The VxWorks scheduler does not support threads in processes, only in the kernel, so concurrency in a user program is achieved with tasks. When using the POSIX scheduler VxWorks is able to create threads as well as tasks. Threads and tasks are by default treated the same by the scheduler and scheduled globally over the system. The VxWorks scheduler is using priority-based pre-emptive scheduling. In VxWorks there are 256 levels of priority, where 0 is considered to be of the highest priority and 255 the lowest. This means that the task with the highest priority (low priority number) will always be selected to run. If there are several tasks with the same priority, the first task will run until it releases the CPU. This may or may not happen, depending on how the task is constructed. This could result in that some tasks are never run if tasks with higher priority or tasks that were scheduled before them never release the CPU. To solve this problem a Round Robin algorithm can be applied to give all tasks a given time slice to run. After the time slice has been consumed the thread is pre-empted and put at the end of the queue again. Scheduling is still priority-based so if there are threads with higher priority they will be selected no matter if Round Robin scheduling is used or not. The POSIX scheduler is a more capable scheduling unit. It supports both threads and tasks and is able to schedule threads both system-wide and on a per process basis. Different scheduling algorithms can also be used either on a process or thread level, the two scheduling algorithms that are available are FIFO and Round Robin.

2.3. Comparison
QNX is using a microkernel; VxWorks is using a monolithic kernel, two completely different approaches when it comes to building an OS. Both have its pros and cons, the microkernel with its small complexity, its scalability can be deployed as a tiny RTOS, only a few hundred kb in size, in an embedded application or as a full feathered advanced RTOS. VxWorks comes in one flavour which can be extended with modules. It is scalable, but does not provide the same liberty for the developer as QNX does. In QNX you can pretty much strip out everything that you do not need, in VxWorks you cant. This is due to how the two RTOS differ in their kernel strategy. Concurrency is an important feature in most modern RTOS, in QNX this is achieved with processes and threads. In VxWorks it can be achieved with processes, threads and tasks
2

Wind River Systems Inc. (2006), VxWorks kernel programmers guide 6.3 TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

depending on the configuration. QNX schedules threads and not processes, scheduling becomes consistent over the system. In a basic setup VxWorks does not support user processes or threads, only tasks. The OS can be configured with POSIX support and process support to give support to these, but scheduling is still limited to only FIFO and Round Robin. When using VxWorks default scheduler scheduling is done globally, all running tasks use the same scheduling algorithm. When using POSIX scheduling it is possible to schedule each thread or process independently. In QNX it is possible to schedule threads with different algorithms independently of each other. Due to the way VxWorks is built it can schedule tasks and threads either globally or on a process- or thread- basis. This is not possible in QNX, since it does not differentiate threads from each other, it does not matter what process a thread might belong to, all threads in the system is treated the same. VxWorks comes short when it comes to scheduling algorithms; three scheduling algorithms exist in QNX, FIFO, Round Robin and Sporadic Scheduling. Only two of them coexist in VxWorks, FIFO and Round Robin. The different algorithms work the same way in both systems, and are used together with different priority levels. Both RTOS apply priority-based pre-emptive scheduling, which means that the process/thread/task of the highest priority will always run.

3. Memory Management
3.1. QNX3
The memory management unit (MMU) in QNX uses page tables to map virtual memory to the physical memory. The virtual memory is, which the name indicates only an image of the real memory, and visible only for the applications running on the computer. When a process accesses an address in what it sees as the physical memory, the CPU translates the address from the virtual memory according to a page table and then redirects the call to the real physical memory so that the right data is read or written by the program. This process is only visible to the CPU. Every application that starts gets its own share of memory which it sees as a continuous range of empty space. That is the virtual memory projected to it by the CPU. The actual memory space given to a program can be spread out in small segments all over the physical memory, but this is not a problem since all the addresses are saved in the page tables. The page table also holds information about where the process is allowed to both read and write and where it is only allowed to read from. There are page tables for every application running and for every process entering the CPU the corresponding page table is loaded. In QNX, if a process has several threads it wont be necessary for a switch of page tables when switching between threads. It often happens that the size of the page tables outgrow the memory in the processor when handling many processes at the same time. To handle this and still be able to work fast the processor puts the page tables in a transition look-aside buffer (TLB) in the cache memory. By doing this it can still access the page tables very fast and thus keeping the performance high. If there isnt enough space in the TLB the CPU has to store the page tables elsewhere and this might slow the MMU down. Different system precautions have been developed to minimize these so called misses, when the desired data isnt in the TLB.
3

QNX Software Systems Ltd. (2003), System Architecture guide

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

The MMU divides the computers memory into 4k blocks and all the blocks in a page table are by QNX referred to as an arena. The free memory is kept on a double linked list so when a process requests for addition memory space the MMU searches the list using a first-fit algorithm. When a sufficient space is found, that memory is allocated for the process. When memory is returned to the system it is added to the list of empty space and adjacent blocks are automatically merged. The double linking enables merging in both directions and helps prevent fragmentation. If all the memory in an entire page-table is freed the block is returned to the system. When developing a system, the memory management can assist by alerting when a memory violation occurs. For example if a pointer has the wrong memory address it can damage data allocated for another thread making that process crash later. Instead of finding out about the error when the crash actually occurs, the MMU alerts the user instantly when the wrong memory is accessed. This helps save a lot of time and debugging. QNX has not only memory protection in the developer environment but it is also active during runtime. This feature makes the OS aware of that a thread has performed an illegal memory operation, such as writing outside its dedicated memory, and the thread in question can be aborted. This reduces the systems performance some, but as QNX states in their documentation, the slight loss in speed is made up by the greater reliability of the system. As good as all embedded systems have a watchdog timer to prevent a system failure from irreversible crashing the whole system and instead only do a restart. But since a restart leads to a system downtime, QNX has another feature that gives the CPU other alternatives when facing an error instead of just restarting. When signalled it can decide to only restart the process where the error occurred or if necessary also related processes. If the embedded system has any type of storage possibilities or is connected to a network it can store information about a system failure making future debugging easier and help to prevent the same failure from occurring again.

3.2. VxWorks
In earlier versions of VxWorks the first-fit algorithm was used when finding an empty space in a single linked list of memory blocks. This algorithm leads to a somewhat fragmented system since it allocates the first available space for the data even if the space is too large. Eventually the free spaces that are left get so small and scattered that it no longer can be used to store data. In newer versions of VxWorks the best-fit algorithm is introduced. The best suitable memory space can now be allocated for the data via a heap structure holding all the empty memory space.4 To keep track of which memory each process can access and modify VxWorks has a virtual memory page for every 4 KB of data. These pages hold information about read and write properties for the memory associated with it. If the processor supports it, VxWorks can change the size of the virtual memory pages. This can enhance the performance of the system and reduces the use of memory. If a large page is set with the same attributes for example read only, and some of the data need to be changed the system automatically handles this. It breaks down the pages in smaller pieces setting the requested attributes to the page containing the
4

Laszlo, Zoltan, Wind River Systems Inc. (2005), Memory Allocation in VxWorks 6.0

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

data in question. In case a processor lacks a MMU or has it disabled, VxWorks can be configured and run without it. Then the memory is handled by a library in the software instead. In this case setting page attributes is not possible, neither is memory protection.5 The use of the TLB for storing virtual memory pages in VxWorks can be modified by the programmer. If there are processes running often in the processor their place in the TLB can automatically be set to permanent if the programmer enables this option. This speeds up the performance of the system since there wont be any switching needed in the TLB. One disadvantage with this is that the TLB has a limited size and making too many memory pages permanent there will naturally decimate the remaining space. Thus the processes remaining that arent used as frequently will have to be shifted in and out of the TLB more often, slowing them down.5 VxWorks has several components which help finding errors in the code while programming. There are a lot of possibilities for the user to get assistance from the system while programming by including these components in the kernel. The programmer can choose from a wide selection of functions in the system and they can be adjusted depending on the task being performed. During runtime to get the system more stable VxWorks has some features for protecting the memory. For example a guard zone can be applied on the stack preventing it from intruding on the rest of the memory in case it starts growing beyond its allocated memory.5

3.3. Comparison
Both operative systems have run time memory protection. But like several other features VxWorks seems to have more possibilities to tweak their functions. They leave more things up to the programmer to decide how they want things to work. However, both OS can signal when detecting programming errors and where to locate them. This helps to prevent the risk of letting a bug go unnoticed into a final product. Would this happen anyway there are functions in both OS that keep their processors running even if a glitch occurs. Both OS use a TLB for fast handling of their page tables. Here they most certain have different solutions to the problem of minimizing misses, since this is the big issue in optimizing the speed and performance of memory handling. There was no description on how any of them solved the problem. VxWorks however has the option to let the programmer decide if the processor will be able to permanently put frequently used page tables in the TLB for faster access. Another difference is that in VxWorks each task can if allowed access the whole memory. This opens some possibilities such as shared memory but it also increases the risk of corrupting data. In QNX each process has its own memory space and that prevents different processes from writing to each others data. QNX uses the MMU in all their systems while VxWorks has the possibility to work without it. Clearly, using a MMU is better than not using one for almost all situations because the advantages are greater. Though, here are still systems where it might be better not using it. And of course if the hardware lacks support for the MMU it is good if the OS can work without it.

Wind River Systems Inc. (2006), VxWorks kernel programmers guide 6.3

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report

LiTH 2013-06-28

QNX handles the free memory in a double linked list which naturally is better than a single linked list as VxWorks had before. With the new heap structure used in VxWorks in addition to the best fit algorithm they seem to have passed QNX in memory management performance. QNX claims to have good solutions to the fragmentation problem but instinctively the best fit algorithm seems better than the first fit, at least when it comes to optimizing the use of available memory. And thats also another aspect of the problem since the systems performance depends on the processor they are running on. Most certain they have both their own field of application they handle better than the other one, but overall VxWorks seems to have found the best combination of data structure and algorithm.

4. Conclusion
VxWorks has a more complex scheduling strategy, is less scalable and supports fewer scheduling algorithms than QNX. VxWorks is a highly customizable system with a lot of features, perhaps too many? Since it is so complex with its many functions and options it seems to have a high learning curve and demands a lot of time and experience from the developer to be able to use the system. For example when you start from scratch with a VxWorks system it is only able to run tasks and has a primitive setup of scheduling. It has a lot of potential but is depending on additional modules, for instance the POSIX-library must be included to use threads. QNX on the other hand seems to be more straight forward and more similar to a regular OS. By the looks of it, it is simpler to use but still it can provide all the functionality that VxWorks can. If choosing between these two operative systems for a new product, it doesnt really matter which one is chosen looking only at the functionality and reliability. What differs the most is the technical aspects, what strategies used when implementing the operative systems. They both have their advantages and disadvantages as well as their special field of application in which they are the most applicable.

TDDB72 Patrik Alnefelt Marcus Svensson

RTOS Report References QNX Software Systems Ltd. (2003), System Architecture guide [www] <http://www.qnx.com>

LiTH 2013-06-28

Laszlo, Zoltan, Wind River Systems Inc. (2005), Memory Allocation in VxWorks 6.0 [www] <http://www.windriver.com> Nagarajan, Shiv; Craig, Robert QNX Software Systems Ltd. (2005), Porting Legacy Systems from VxWorks to QNX Neutrino RTOS [www] <http://www.qnx.com> Wind River Systems Inc. (2006), VxWorks kernel programmers guide 6.3

TDDB72 Patrik Alnefelt Marcus Svensson

10