Primary Multicore Software Configurations

Many people ask the question as to what the best approach would be for them to go to multicore and/or virtualization. This is a great question to start a discussion as there is not a single silver bullet. I meant to post a quick diagram on the different multicore configurations before, but life has been busy since we announced the Wind River Hypervisor earlier this year. Busy in this case is certainly a good thing.

I frequently use the graphic below to hold the discussion around. An easy graphic to draw on a white board, or to put on a projector and a sure fire way to get the discussion going. I also posted this earlier article on <a href="http://www.edn.com/blog/1200000320/post/1350046135.html">EDN on multicore configurations</a>.

The "Traditional" option needs little further discussion, it is how people have been developing systems. Choose an OS to go with the processor and you are done.

SMP and unsupervised AMP are the 'usual suspects' to low-core-count multicore processors. Symmetric Multiprocessing (SMP) gives all cores to a single kernel. This works well in low core count environments, but especially when the core count goes up and lots of small work packets have to be handled (interrupts, IP packets), then the impact of the single scheduler becomes evident. This can be countered partially by core affinity or reservation. SMP also runs a single OS, if it crashes for some reason, then the entire system goes down.

Unsupervised AMP for Asynchronous Multiprocessing runs multiple operating systems, one per core. This has the advantage of being able to run say VxWorks and Linux and will also keep the system 'up' if one crashes. However, establishing the separation of multiple operating systems on top of a single processor with shared memory, shared devices and such is not trivial. Ask anyone who has done this before, it requires detailed expertise on how the processor works as well as how the operating system uses the processor. The partitioning provided by AMP can solve the scalability problem of SMP, but only if the algorithm is well parallellizable (which is a different problem altogether).

Virtualization provides Supervised AMP, which provides the benefits of AMP, but without the  technical hassles and with the benefit of flexibility. The virtualization layer creates the partitions (Virtual Boards) to run the operating systems within and then gets out of the way. The virtualization layer in this case is referred to as a 'supervisor', as there is very little run-tim impact of virtualization. 

Supervised AMP is a great way to provide consolidation of an existing system that utilizes multiple single core processors into a single multicore processor (as the parallallization in that case has already been established in the existing device). 

The last configuration in this list is the virtualized scenario in the upper right hand corner. This scenario uses core-virtualization, that is, it schedules multiple different virtual boards on top of a single physical processing core. This of course has impact on the amount of processing power that each virtual board gets. Luckily this scenario still provides determinism, that is, say you run VxWorks and Linux on top of a single core, VxWorks can still have real-time characteristics that you expect from an RTOS, while Linux can provide the services of a typical General Purpose Operating System.

Now, the diagram only shows the primary configurations, these configurations can be combined, for example an SMP virtual board within a sAMP system, or core virtualization on one core with sAMP on the others.

Again, which configuration is best for you... That depends, where do you come from, where are you going towards, what processor architecture do you have an how many cores. This quick overview is certainly not meant as an answer, but it may prove useful to start the discussion. Post questions or discussions below and I will get back to you as soon as I can.

You can also follow me as @markhermeling on Twitter