locktorture.rst

  1.. SPDX-License-Identifier: GPL-2.0
  2
  3.. include:: ../disclaimer-ita.rst
  4
  5============================================
  6Funzionamento del test *Kernel Lock Torture*
  7============================================
  8
  9CONFIG_LOCK_TORTURE_TEST
 10========================
 11
 12L'opzione di configurazione CONFIG_LOCK_TORTURE_TEST fornisce un
 13modulo kernel che esegue delle verifiche che *torturano* le primitive di
 14sincronizzazione del kernel. Se dovesse servire, il modulo kernel,
 15'locktorture', può essere generato successivamente su un kernel che
 16volete verificare. Periodicamente le verifiche stampano messaggi tramite
 17``printk()`` e che quindi possono essere letti tramite ``dmesg`` (magari
 18filtrate l'output con ``grep "torture"``). La verifica inizia quando
 19il modulo viene caricato e termina quando viene rimosso. Questo
 20programma si basa sulle modalità di verifica di RCU tramite rcutorture.
 21
 22Questa verifica consiste nella creazione di un certo numero di thread
 23del kernel che acquisiscono un blocco e lo trattengono per una certa
 24quantità di tempo così da simulare diversi comportamenti nelle sezioni
 25critiche. La quantità di contese su un blocco può essere simulata
 26allargando la sezione critica e/o creando più thread.
 27
 28
 29Parametri del modulo
 30====================
 31
 32Questo modulo ha i seguenti parametri:
 33
 34
 35Specifici di locktorture
 36------------------------
 37
 38nwriters_stress
 39		  Numero di thread del kernel che stresseranno l'acquisizione
 40		  esclusiva dei blocchi (scrittori). Il valore di base è il
 41		  doppio del numero di processori attivi presenti.
 42
 43nreaders_stress
 44		  Numero di thread del kernel che stresseranno l'acquisizione
 45		  condivisa dei blocchi (lettori). Il valore di base è lo stesso
 46		  di nwriters_stress. Se l'utente non ha specificato
 47		  nwriters_stress, allora entrambe i valori corrisponderanno
 48		  al numero di processori attivi presenti.
 49
 50torture_type
 51		  Tipo di blocco da verificare. Di base, solo gli spinlock
 52		  verranno verificati. Questo modulo può verificare anche
 53		  i seguenti tipi di blocchi:
 54
 55		     - "lock_busted":
 56				Simula un'incorretta implementazione del
 57				blocco.
 58
 59		     - "spin_lock":
 60				coppie di spin_lock() e spin_unlock().
 61
 62		     - "spin_lock_irq":
 63				coppie di spin_lock_irq() e spin_unlock_irq().
 64
 65		     - "rw_lock":
 66				coppie di rwlock read/write lock() e unlock().
 67
 68		     - "rw_lock_irq":
 69				copie di rwlock read/write lock_irq() e
 70				unlock_irq().
 71
 72		     - "mutex_lock":
 73				coppie di mutex_lock() e mutex_unlock().
 74
 75		     - "rtmutex_lock":
 76				coppie di rtmutex_lock() e rtmutex_unlock().
 77				Il kernel deve avere CONFIG_RT_MUTEXES=y.
 78
 79		     - "rwsem_lock":
 80				coppie di semafori read/write down() e up().
 81
 82
 83Generici dell'ambiente di sviluppo 'torture' (RCU + locking)
 84------------------------------------------------------------
 85
 86shutdown_secs
 87		  Numero di secondi prima che la verifica termini e il sistema
 88		  venga spento.  Il valore di base è zero, il che disabilita
 89		  la possibilità di terminare e spegnere. Questa funzionalità
 90		  può essere utile per verifiche automatizzate.
 91
 92onoff_interval
 93		  Numero di secondi fra ogni tentativo di esecuzione di
 94		  un'operazione casuale di CPU-hotplug. Di base è zero, il
 95		  che disabilita la funzionalità di CPU-hotplug. Nei kernel
 96		  con CONFIG_HOTPLUG_CPU=n, locktorture si rifiuterà, senza
 97		  dirlo, di effettuare una qualsiasi operazione di
 98		  CPU-hotplug indipendentemente dal valore specificato in
 99		  onoff_interval.
100
101onoff_holdoff
102		  Numero di secondi da aspettare prima di iniziare le
103		  operazioni di CPU-hotplug.  Normalmente questo verrebbe
104		  usato solamente quando locktorture è compilato come parte
105		  integrante del kernel ed eseguito automaticamente all'avvio,
106		  in questo caso è utile perché permette di non confondere
107		  l'avvio con i processori che vanno e vengono. Questo
108		  parametro è utile sono se CONFIG_HOTPLUG_CPU è abilitato.
109
110stat_interval
111		  Numero di secondi fra una stampa (printk()) delle
112		  statistiche e l'altra. Di base, locktorture riporta le
113		  statistiche ogni 60 secondi. Impostando l'intervallo a 0
114		  ha l'effetto di stampare le statistiche -solo- quando il
115		  modulo viene rimosso.
116
117stutter
118		  Durata della verifica prima di effettuare una pausa di
119		  eguale durata. Di base "stutter=5", quindi si eseguono
120		  verifiche e pause di (circa) cinque secondi.
121		  L'impostazione di "stutter=0" fa si che la verifica
122		  venga eseguita continuamente senza fermarsi.
123
124shuffle_interval
125		  Il numero di secondi per cui un thread debba mantenere
126		  l'affinità con un sottoinsieme di processori, di base è
127		  3 secondi. Viene usato assieme a test_no_idle_hz.
128
129verbose
130		  Abilita le stampe di debug, via printk(). Di base è
131		  abilitato. Queste informazioni aggiuntive sono per la
132		  maggior parte relative ad errori di alto livello e resoconti
133		  da parte dell'struttura 'torture'.
134
135
136Statistiche
137===========
138
139Le statistiche vengono stampate secondo il seguente formato::
140
141  spin_lock-torture: Writes:  Total: 93746064  Max/Min: 0/0   Fail: 0
142     (A)		    (B)		   (C)		  (D)	       (E)
143
144  (A): tipo di lock sotto verifica -- parametro torture_type.
145
146  (B): Numero di acquisizione del blocco in scrittura. Se si ha a che fare
147       con una primitiva di lettura/scrittura apparirà di seguito anche una
148       seconda voce "Reads"
149
150  (C): Numero di volte che il blocco è stato acquisito
151
152  (D): Numero minimo e massimo di volte che un thread ha fallito
153       nell'acquisire il blocco
154
155  (E): valori true/false nel caso di errori durante l'acquisizione del blocco.
156       Questo dovrebbe dare un riscontro positivo -solo- se c'è un baco
157       nell'implementazione delle primitive di sincronizzazione. Altrimenti un
158       blocco non dovrebbe mai fallire (per esempio, spin_lock()).
159       Ovviamente lo stesso si applica per (C). Un semplice esempio è il tipo
160       "lock_busted".
161
162Uso
163===
164
165Il seguente script può essere utilizzato per verificare i blocchi::
166
167	#!/bin/sh
168
169	modprobe locktorture
170	sleep 3600
171	rmmod locktorture
172	dmesg | grep torture:
173
174L'output può essere manualmente ispezionato cercando il marcatore d'errore
175"!!!". Ovviamente potreste voler creare degli script più elaborati che
176verificano automaticamente la presenza di errori. Il comando "rmmod" forza la
177stampa (usando printk()) di "SUCCESS", "FAILURE", oppure "RCU_HOTPLUG". I primi
178due si piegano da soli, mentre l'ultimo indica che non stati trovati problemi di
179sincronizzazione, tuttavia ne sono stati trovati in CPU-hotplug.
180
181Consultate anche: Documentation/translations/it_IT/RCU/torture.rst