13-Patal533marsv024-VxWorks QNX Scheduling Memory

7/28/2019 13-Patal533marsv024-VxWorks QNX Scheduling Memory

1/10

RTOS Report LiTH2013-06-28

How VxWorks handles process scheduling andmemory management in comparison to QNX

Patrik Alnefelt [email protected] Svensson [email protected]

TDDB72

Patrik AlnefeltMarcus Svensson
mailto:[email protected]:[email protected]:[email protected]:[email protected]


2/10


INDEX

1. ABSTRACT.........................................................................................................................................................3

2. INTRODUCTION...............................................................................................................................................3

PROCESS SCHEDULING....................................................................................................................................4

2.1. QNX..............................................................................................................................................................42.2. VXWORKS......................................................................................................................................................5

2.3. COMPARISON..................................................................................................................................................5

3. MEMORY MANAGEMENT.............................................................................................................................6

3.1. QNX..............................................................................................................................................................63.2. VXWORKS......................................................................................................................................................7

3.3. COMPARISON..................................................................................................................................................8

4. CONCLUSION....................................................................................................................................................9

TDDB72 2



3/10


1. AbstractThe 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. IntroductionIn 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 3



4/10


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 prioritythat 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 theback 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 Architectureguide

TDDB72 4



5/10


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 tasksrun 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 isstill 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 microkernelwith 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.3TDDB72 5



6/10


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 eachthread 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 willalways 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 addressfrom 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 Architectureguide

TDDB72 6



7/10


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 helpsprevent 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 memoryoperation, 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 theempty 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

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

TDDB72 7



8/10


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 canautomatically 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 taskbeing 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 signalwhen 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 therisk 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.

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

TDDB72 8



9/10


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 systemsperformance 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. ConclusionVxWorks 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 thedeveloper 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 9



10/10


References

QNX Software Systems Ltd. (2003), System Architectureguide [www]

Laszlo, Zoltan, Wind River Systems Inc. (2005),Memory Allocation in VxWorks6.0 [www]

Nagarajan, Shiv; Craig, Robert QNX Software Systems Ltd. (2005),Porting Legacy Systems

from VxWorks to QNX Neutrino RTOS[www]

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

TDDB72 10

http://www.qnx.com/http://www.windriver.com/http://www.qnx.com/http://www.qnx.com/http://www.windriver.com/http://www.qnx.com/

Documents

13-Patal533marsv024-VxWorks QNX Scheduling Memory