You have a kernel option configuration where a CPU won't be used by the OS, it is called
isolcpus — Isolate CPUs from the kernel scheduler.
Synopsis isolcpus= cpu_number [, cpu_number ,...]
Description Remove the specified CPUs, as defined by the cpu_number
values, from the general kernel SMP balancing and scheduler
algroithms. The only way to move a process onto or off an "isolated"
CPU is via the CPU affinity syscalls. cpu_number begins at 0, so the
maximum value is 1 less than the number of CPUs on the system.
This configuration I am about to describe how to setup, can have far more uses than for testing.
Meru for instance, uses this technology in their Linux-based AP controllers, to keep the network traffic from interfering with the inner workings of the OS, namely I/O operations.
I also use it in a very busy web frontend, for quite the same reasons: I have found out from life experience that I lost control too regularly for my taste of that server ; had to reboot it forcefully until I separated the front end daemon on it´s own dedicated CPUs.
As you have 8 CPUs, that you can check with the output of the command:
$ grep -c proc /proc/cpuinfo
$ lscpu | grep '^CPU.s'
Add in Debian/Ubuntu in the file
/etc/default/grub to the option
(it is 7, because it starts in 0, and you have 8 cores)
This is telling the kernel to not use one of your cores.
Reboot the system.
Then start your process.
Immediately after starting it, you can change for the 8th CPU (7 because 0 is the 1st), and be quite sure you are the only one using that CPU.
For that, use the command:
taskset -cp 7 PID_number
taskset - retrieve or set a processes’s CPU affinity
taskset [options] [mask | list ] [pid | command [arg]...]
taskset is used to set or retrieve the CPU affinity of a running pro
cess given its PID or to launch a new COMMAND with a given CPU affinity. CPU affinity is a scheduler property that "bonds" a process to a
given set of CPUs on the system. The Linux scheduler will honor the
given CPU affinity and the process will not run on any other CPUs.
Note that the Linux scheduler also supports natural CPU affinity: the
scheduler attempts to keep processes on the same CPU as long as practical for performance reasons. Therefore, forcing a specific CPU affinity is useful only in certain applications.
For reading more about it, see: isolcpus, numactl and taskset
ps -eF you should see in the PSR column the processor being used.
I have a server with CPU 2 and 3 isolated, and indeed, it can be seen with
ps -e the only process in userland as intended, is
# ps -eo psr,command | tr -s " " | grep "^ [2|3]"
If you compare it with the non-isolated CPUs, they are running many more things (the window below slides):
# ps -eo psr,command | tr -s " " | grep "^ [0|1]"
0 init 
0 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
1 /usr/sbin/snmpd -Lf /dev/null -u snmp -g snmp -I -smux -p /var/run/snmpd.pid
1 /sbin/getty 38400 tty1
1 /lib/systemd/systemd-udevd --daemon
0 /usr/sbin/xinetd -pidfile /run/xinetd.pid -stayalive
0 /usr/bin/monit -c /etc/monit/monitrc
0 sshd: rui [priv]
0 sshd: rui@pts/0,pts/1
0 sudo su
0 logger -t cmdline root[/home/rui]
1 ps -eo psr,command
0 tr -s
0 grep ^ [0|1]