Kdb+ can be constrained to run on specific cores through the setting of CPU affinity.
Typically, you can set the CPU affinity for the shell you are in, and then processes started within that shell will inherit the affinity.
The following commands will show if NUMA is active.
$ grep NUMA=y /boot/config-`uname -r` CONFIG_NUMA=y CONFIG_AMD_NUMA=y CONFIG_X86_64_ACPI_NUMA=y CONFIG_ACPI_NUMA=y
Or test for the presence of NUMA maps.
$ find /proc -name numa_maps /proc/12108/numa_maps /proc/12109/task/12109/numa_maps /proc/12109/numa_maps ...
Q and NUMA
Until Linux kernels 3.x, q and NUMA did not work well together.
When activating NUMA, substitute parameter settings according to the recommendations for different Linux kernels.
When NUMA is
- not active, use the
will run q on cores 0, 1 and 2. Or
$ taskset -c 0,1,2 q
and then all processes started from within that new shell will automatically be restricted to those cores.
$ taskset -c 0,1,2 bash
- active, use
$ numactl --interleave=all --physcpubind=0,1,2 q
$ echo 0 > /proc/sys/vm/zone_reclaim_mode
You can change
zone_reclaim_mode without restarting q.
Other ways to limit resources
On Linux systems, administrators might prefer cgroups as a way of limiting resources.
On Unix systems, memory usage can be constrained using
limits virtual address space to 256MB.
$ ulimit -v 262144
$ psrset -e 2 q
which will run q using processor set 2. Or, to start a shell restricted to those cores:
$ psrset -e 2 bash
Start q.exe with the OS command
start with the
/affinity flag set
C> start /affinity 3 c:\q\w64\q.exe
will run q on core 0 and 1.