SPEC CPU®2026 Flag Description
NVIDIA NVIDIA DGX Spark (3.9 GHz NVIDIA GB10 CPU)

Test sponsored by Arm

Flag descriptions for LLVM

Note: The LLVM compilers provide a wide array of compiler options, occasionally described in detail and readily available at https://clang.llvm.org/docs/ClangCommandLineReference.html and https://flang.llvm.org/docs/FlangCommandLineReference.html. This SPEC CPU flags file contains excerpts from and brief summaries of portions of that documentation.

SPEC's modifications are:
Copyright 2026 Standard Performance Evaluation Corporation

Permission is granted to copy, distribute and/or modify this document under the terms of the Apache v2.0 License with LLVM Exceptions.

Commands and Options Used to Submit Benchmark Runs

SPECrate runs might use one of these methods to bind processes to specific processors, depending on the config file.

• Linux systems: the numactl command is commonly used. Here is a brief guide to understanding the specific command which will be found in the config file:

  • syntax: numactl [--interleave=nodes] [--preferred=node] [--physcpubind=cpus] [--cpunodebind=nodes] [--membind=nodes] [--localalloc] command args ...
  • numactl runs processes with a specific NUMA scheduling or memory placement policy. The policy is set for a command and inherited by all of its children.
  • --localalloc instructs numactl to keep a process memory on the local node while -m specifies which node(s) to place a process memory.
  • --physcpubind specifies which core(s) to bind the process. In this case, copy 0 is bound to processor 0, etc.
  • For full details on using numactl, please refer to your Linux documentation, man numactl

• macOS systems: processes are not bound.

Commands and Options Used for Feedback-Directed Optimization

No special commands are needed for feedback-directed optimization, other than the compiler profile  flags.

Shell, Environment, and Other Software Settings

One or more of the following may have been used in the run. If so, it will be listed in the notes sections. Here is a brief guide to understanding them:

• LD_LIBRARY_PATH=<directories> (set via config file preENV)
  LD_LIBRARY_PATH controls the search order for libraries. Often, it can be defaulted. Sometimes, it is explicitly set (as documented in the notes in the submission) in order to ensure that the correct versions of libraries are picked up.

• OMP_STACKSIZE=N (set via config file preENV)
  Set the stack size for subordinate OpenMP threads.

• ulimit -s N
  ulimit -s unlimited
  'ulimit' is a Unix command, entered prior to the run. It sets the stack size for the main process and its children, either to N kbytes or to no limit.

• MALLOC_CONF=thp:always,metadata_thp:always (set via config file preENV)
  MALLOC_CONF controls jemalloc behavior.

  1. The "thp" option controls whether heap allocations jemalloc does use transparent huge pages, if THP is supported by the operating system. The "always" setting enables transparent hugepage for all user memory mappings with MADV_HUGEPAGE; "never" ensures no transparent hugepage with MADV_NOHUGEPAGE; the default setting "default" makes no changes.

  2. The "metadata_thp" option controls whether to allow jemalloc to use transparent huge pages (THP) for internal metadata. The "always" setting allows such usage. The "auto" setting uses no THP initially, but may begin to do so when metadata usage reaches certain level. The default is "disabled".

Operating System Tuning Parameters

kernel.randomize_va_space (ASLR)

This setting can be used to select the type of process address space randomization. Defaults differ based on whether the architecture supports ASLR, whether the kernel was built with the CONFIG_COMPAT_BRK option or not, or the kernel boot options used.
Possible settings:

• 0: Turn process address space randomization off.
• 1: Randomize addresses of mmap base, stack, and VDSO pages.
• 2: Additionally randomize the heap. (This is probably the default.)

Disabling ASLR can make process execution more deterministic and runtimes more consistent. For more information see the randomize_va_space entry in the Linux sysctl documentation.

Transparent Hugepages (THP)

THP is an abstraction layer that automates most aspects of creating, managing, and using huge pages. It is designed to hide much of the complexity in using huge pages from system administrators and developers. Huge pages increase the memory page size from 4 kilobytes to 2 megabytes. This provides significant performance advantages on systems with highly contended resources and large memory workloads. If memory utilization is too high or memory is badly fragmented which prevents hugepages being allocated, the kernel will assign smaller 4k pages instead. Most recent Linux OS releases have THP enabled by default.
THP usage is controlled by the sysfs setting /sys/kernel/mm/transparent_hugepage/enabled. Possible values:

• never: entirely disable THP usage.
• madvise: enable THP usage only inside regions marked MADV_HUGEPAGE using madvise(3).
• always: enable THP usage system-wide. This is the default.

THP creation is controlled by the sysfs setting /sys/kernel/mm/transparent_hugepage/defrag. Possible values:

• never: if no THP are available to satisfy a request, do not attempt to make any.
• defer: an allocation requesting THP when none are available get normal pages while requesting THP creation in the background.
• defer+madvise: acts like "always", but only for allocations in regions marked MADV_HUGEPAGE using madvise(3); for all other regions it's like "defer".
• madvise: acts like "always", but only for allocations in regions marked MADV_HUGEPAGE using madvise(3). This is the default.
• always: an allocation requesting THP when none are available will stall until some are made.

An application that "always" requests THP often can benefit from waiting for an allocation until those huge pages can be assembled.
For more information see the Linux transparent hugepage documentation.

dirty_ratio

This is a percentage value of total available memory that can be filled with dirty data before writing the modifications to disk. Set through "sysctl -w vm.dirty_ratio=8".

swappiness

This control is used to define how aggressive the kernel will swap memory pages. Increaasing the value causes swapping more frequently. The default value is 60. A value of 1 tells the kernel to only swap processes to disk if absolutely necessary. This can be set through a command like "sysctl -w vm.swappiness=1"

zone_reclaim_mode

Zone_reclaim_mode allows someone to set more or less aggressive approaches to reclaim memory when a zone runs out of memory. It controls whether memory reclaim is performed on a local NUMA node or other nodes. To tell the kernel to free local node memory rather than grabbing free memory from remote nodes, it can be set through a command like "sysctl -w vm.zone_reclaim_mode=1".

drop_caches

Writing this will cause kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free. Set through "sysctl -w vm.drop_caches=3" to free slab objects and pagecache.

CPUFreq scaling governor:

Governors are power schemes for the CPU. It is in-kernel pre-configured power schemes for the CPU and allows you to change the clock speed of the CPUs on the fly. On Linux systems can set the govenor for all CPUs through the cpupower utility with the following command:

• "cpupower -c all frequency-set -g governor"

Below are govenors in the Linux kernel.

• performance: Run the CPU at the maximum frequency.
• powersave: Run the CPU at the minimum frequency.
• userspace: Run the CPU at user specified frequencies.
• ondemand: Scales the frequency dynamically according to current load. Jumps to the highest frequency and then possibly back off as the idle time increases.
• conservative: Scales the frequency dynamically according to current load. Scales the frequency more gradually than ondemand.
• schedutil: Scheduler-driven CPU frequency selection.

tuned-adm:

A commandline interface for switching between different tuning profiles available in supported Linux distributions. The distribution provided profiles are located in /usr/lib/tuned and the user defined profiles in /etc/tuned. To set a profile, one can issue the command "tuned-adm profile (profile_name)". Below are details about some relevant profiles.

• throughput-performance: For typical throughput performance tuning. Disables power saving mechanisms and enables sysctl settings that improve the throughput performance of disk and network I/O. CPU governor is set to performance and CPU energy performance bias is set to performance. Disk readahead values are increased.
• latency-performance: For low latency performance tuning. Disables power saving mechanisms. CPU governor is set to performance and locked to the low C states. CPU energy performance bias to performance.
• balanced: Default profile provides balanced power saving and performance. It enables CPU and disk plugins of tuned and makes the conservative governor is active and also sets the CPU energy performance bias to normal. It also enables power saving on audio and graphics card.
• powersave: Maximal power saving for whole system. It sets the CPU governor to ondemand governor and energy performance bias to powersave. It also enable power saving on USB, SATA, audio and graphics card.

Flag description origin markings:

	Indicates that the flag description came from the user flags file.
	Indicates that the flag description came from the suite-wide flags file.
	Indicates that the flag description came from a per-benchmark flags file.

For questions about the meanings of these flags, please contact the tester.
For other inquiries, please contact info@spec.org
Copyright 2026 Standard Performance Evaluation Corporation
Tested with SPEC CPU®2026 v0.902.0.
Report generated on 2026-08-11 15:14:08 by SPEC CPU®2026 flags formatter (5b352a85).