Browse Prior Art Database

Method to Simulate NUMA Topologies to Facilitate Testing of NUMA Aware Systems and Software

IP.com Disclosure Number: IPCOM000249256D
Publication Date: 2017-Feb-14
Document File: 2 page(s) / 30K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to represent the non-uniform memory access (NUMA) topology in an operating system using low-level data structures that are typically configured when resources are discovered at boot, migration, or when resuming from hibernation. This addresses the problem of attempting to test the functional correctness of such NUMA optimizations across the myriad of different potential NUMA topologies such as memory only nodes,

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

1

Method to Simulate NUMA Topologies to Facilitate Testing of NUMA Aware Systems and Software

Multiprocessing computers using non-uniform memory access (NUMA) often require complex

and clever ways of optimizing the various workloads across the different Central Processing Unit

(CPU) and memory topologies. Additionally, new features and function added to the operating

system (OS) sometimes require or include NUMA optimizations.

This disclosure address the problem of attempting to test the functional correctness of

such NUMA optimizations across the myriad of different potential NUMA topologies such as

memory only nodes, CPU only nodes, severely unbalanced nodes, and so forth. The novel

solution represents the NUMA topology in an operating system using low-level data structures

that are typically configured when resources are discovered at boot, migration, or when resuming

from hibernation.

During boot, the topology is queried directly by the kernel, and its internal data structure

representations are set up long before any programs are able to run. However, during the

resuming or migration of a virtual machine (VM), an open operating system uses a system

program to query the new topology and then call the kernel to recreate its internal data structure

representations of that new topology. This idea leverages this dynamic topology-updating

infrastructure by replacing the program that performs the topology query and kernel update calls

with a similar program that interjects an added function after the query function and before the

kernel calls. The interjected function alters the topology of the CPU and logical memory block

(LMB) resources found in the query, per user specifications. The user can specify:

Generic descriptions of the intended topology changes such as "Node0=25% CPUs and 75% 

LMBs, Node1=33% CPUs and 10% LMBS, ..." or "Node0=2 CPUs and 0 LMBs, ..."

Detailed descriptions of where each resource should go such as "CPU0=Node0, 

CPU1=Node1, LMB0=Node3, ..."

The system uses these user specifications to change the queried topology information before

calling into the kernel to update the operating system's internal data structures. Function

verification tests can then dynamically alter the topology based on the assertion being tested.

The solution can include a graphical user interface (GUI) to facilitate the resource and

topology specification of each different topology simulation needed. The system can save each

unique simulated topology in a file that passes into the simulation program to convert into the

format that then passes into the kernel to update its internal topology data structures. In the case

of an open operating system, the NUMA topology is represented as a list of CPU and LMB

resources. The resources are physically grouped on the hardware box by connection. A group of

CPUs soldered onto the same socket is considered distinctly separate from those in another

socket; a group of CPU sockets attached directly to a memory co...