Come garantire la disponibilità esclusiva della CPU per un processo in esecuzione?

Inizialmente, la domanda sembra essere un po 'sciocca / confusa poiché il sistema operativo svolge il compito di gestire l'esecuzione del processo.

Tuttavia, voglio misurare quanto alcuni processi sono legati alla CPU / IO e sento che il mio sistema operativo interferisce con i miei esperimenti con, ad esempio, i processi del sistema operativo pianificati.

Prendiamo ad esempio la seguente situazione: Ho eseguito il processo A due volte e ho ottenuto il seguente output dallo strumento "time" (colonne temporali in secondi):

+---+-------+---------+-----------+---------+
|Run|Process|User Time|System Time|Wall time|
+---+-------+---------+-----------+---------+
|1  |A      |196.3    |5.12       |148.86   |
|2  |A      |190.79   |4.93       |475.46   |
+---+-------+---------+-----------+---------+

Come possiamo vedere, sebbene il tempo dell'utente e quello del sistema siano simili, il tempo trascorso di entrambi cambia drasticamente (diff. Di ~ 5 min). Sembra che qualcosa nel mio ambiente abbia causato una sorta di contesa.

Voglio interrompere ogni possibile processo / servizio in background per evitare qualsiasi tipo di rumore durante i miei esperimenti, ma mi considero un utente unix principiante / intermedio e non so come garantirlo.

Sto usando Linux 4.4.0-45-generico con Ubuntu 14.04 LTS a 64 bit.

Apprezzo molto l'assistenza. Se avete bisogno di informazioni mancanti, modificherò prontamente il mio post.

Informazioni sulla CPU

$ grep proc /proc/cpuinfo | wc -l
8
$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                8
On-line CPU(s) list:   0-7
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 60
Stepping:              3
CPU MHz:               4002.609
BogoMIPS:              7183.60
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-7

Hai una configurazione delle opzioni del kernel in cui una CPU non verrà utilizzata dal sistema operativo, si chiama isolcpus.

isolcpus - Isola le CPU dallo scheduler del kernel.

Sinossi isolcpus = cpu_number [, cpu_number, ...]

Descrizione Rimuovere le CPU specificate, come definite dai valori cpu_number, dagli algroit di scheduler e di bilanciamento SMP del kernel generale. L'unico modo per spostare un processo all'interno o all'esterno di una CPU "isolata" è tramite le syscalls di affinità della CPU. cpu_number inizia da 0, quindi il valore massimo è 1 in meno rispetto al numero di CPU sul sistema.

Questa configurazione che sto per descrivere come impostare, può avere molti più usi che per i test.

Meru, ad esempio, utilizza questa tecnologia nei propri controller AP basati su Linux, per impedire al traffico di rete di interferire con il funzionamento interno del sistema operativo, vale a dire le operazioni di I / O.

Lo uso anche in un frontend Web molto impegnato, per gli stessi motivi: ho scoperto dall'esperienza di vita che ho perso il controllo troppo regolarmente per i miei gusti di quel server; ho dovuto riavviarlo forzatamente fino a quando non ho separato il demone front-end sulle sue CPU dedicate.

Poiché hai 8 CPU, puoi verificare con l'output del comando:

$ grep -c proc /proc/cpuinfo
8

o

$ lscpu | grep '^CPU.s'
CPU(s):                8

Aggiungi in Debian / Ubuntu nel file /etc/default/gruball'opzione GRUB_CMDLINE_LINUX:

GRUB_CMDLINE_LINUX="isolcpus=7"

(è 7, perché inizia tra 0 e hai 8 core)

Quindi corri,

sudo update-grub

Questo sta dicendo al kernel di non usare uno dei tuoi core.

Riavvia il sistema.

Quindi avviare il processo.

Immediatamente dopo averlo avviato, è possibile cambiare per l'ottava CPU (7 perché 0 è il primo) ed essere abbastanza sicuri di essere l'unico a utilizzare quella CPU.

Per questo, usa il comando:

taskset -cp 7 PID_number

tasket: recupera o imposta l'affinità della CPU di un processo

SINOSSI

   taskset [options] [mask | list ] [pid | command [arg]...]

DESCRIZIONE

tasket viene utilizzato per impostare o recuperare l'affinità CPU di un processo in esecuzione dato il suo PID o per lanciare un nuovo COMANDO con una determinata affinità CPU. L'affinità della CPU è una proprietà dello scheduler che "lega" un processo a un determinato set di CPU sul sistema. Lo scheduler di Linux rispetterà l'affinità della CPU data e il processo non verrà eseguito su altre CPU. Si noti che lo scheduler Linux supporta anche la naturale affinità della CPU: lo scheduler tenta di mantenere i processi sulla stessa CPU per tutto il tempo pratico per motivi di prestazioni. Pertanto, forzare una specifica affinità della CPU è utile solo in alcune applicazioni.

Per saperne di più, vedi: isolcpus, numactl e tasket

Anche usando ps -eFsi dovrebbe vedere nella colonna PSR il processore in uso.

Ho un server con CPU 2 e 3 isolata, e infatti, può essere visto con ps -el'unico processo in userland come previsto, è pound.

# ps -eo psr,command | tr -s " " | grep "^ [2|3]"
 2 [cpuhp/2]
 2 [watchdog/2]
 2 [migration/2]
 2 [ksoftirqd/2]
 2 [kworker/2:0]
 2 [kworker/2:0H]
 3 [cpuhp/3]
 3 [watchdog/3]
 3 [migration/3]
 3 [ksoftirqd/3]
 3 [kworker/3:0]
 3 [kworker/3:0H]
 2 [kworker/2:1]
 3 [kworker/3:1]
 3 [kworker/3:1H]
 3 /usr/sbin/pound

Se lo confronti con le CPU non isolate, stanno eseguendo molte più cose (la finestra sotto le diapositive ):

# ps -eo psr,command | tr -s " " | grep "^ [0|1]"
 0 init [2]
 0 [kthreadd]
 0 [ksoftirqd/0]
 0 [kworker/0:0H]
 0 [rcu_sched]
 0 [rcu_bh]
 0 [migration/0]
 0 [lru-add-drain]
 0 [watchdog/0]
 0 [cpuhp/0]
 1 [cpuhp/1]
 1 [watchdog/1]
 1 [migration/1]
 1 [ksoftirqd/1]
 1 [kworker/1:0]
 1 [kworker/1:0H]
 1 [kdevtmpfs]
 0 [netns]
 0 [khungtaskd]
 0 [oom_reaper]
 1 [writeback]
 0 [kcompactd0]
 0 [ksmd]
 1 [khugepaged]
 0 [crypto]
 1 [kintegrityd]
 0 [bioset]
 1 [kblockd]
 1 [devfreq_wq]
 0 [watchdogd]
 0 [kswapd0]
 0 [vmstat]
 1 [kthrotld]
 0 [kworker/0:1]
 0 [deferwq]
 0 [scsi_eh_0]
 0 [scsi_tmf_0]
 1 [vmw_pvscsi_wq_0]
 0 [bioset]
 1 [jbd2/sda1-8]
 1 [ext4-rsv-conver]
 0 [kworker/0:1H]
 1 [kworker/1:1H]
 1 [bioset]
 0 [bioset]
 1 [bioset]
 1 [bioset]
 1 [bioset]
 1 [bioset]
 1 [bioset]
 1 [bioset]
 0 [jbd2/sda3-8]
 1 [ext4-rsv-conver]
 1 /usr/sbin/rsyslogd
 0 /usr/sbin/irqbalance --pid=/var/run/irqbalance.pid
 1 /usr/sbin/cron
 0 /usr/sbin/sshd
 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
 1 [kworker/1:2]
 0 [kworker/u128:1]
 0 [kworker/0:2]
 0 [bioset]
 1 [xfsalloc]
 1 [xfs_mru_cache]
 1 [jfsIO]
 1 [jfsCommit]
 0 [jfsCommit]
 0 [jfsCommit]
 0 [jfsCommit]
 0 [jfsSync]
 1 [bioset]
 0 /usr/bin/monit -c /etc/monit/monitrc
 1 /usr/sbin/pound
 0 sshd: rui [priv]
 0 sshd: rui@pts/0,pts/1
 1 -bash
 1 -bash
 1 -bash
 1 [kworker/u128:0]
 1 -bash
 0 sudo su
 1 su
 1 bash
 0 bash
 0 logger -t cmdline root[/home/rui] 
 1 ps -eo psr,command
 0 tr -s 
 0 grep ^ [0|1]
 0 /usr/bin/vmtoolsd