Lines Matching +full:sh +full:- +full:rtc
1 .. SPDX-License-Identifier: GPL-2.0
3 .. include:: ../disclaimer-ita.rst
19 Documentation/admin-guide/kernel-parameters.txt.
26 …rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_…
27 …rcu-torture: rtc: (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0…
28 rcu-torture: Reader Pipe: 727860534 34213 0 0 0 0 0 0 0 0 0
29 rcu-torture: Reader Batch: 727877838 17003 0 0 0 0 0 0 0 0 0
30 …rcu-torture: Free-Block Circulation: 155440 155440 155440 155440 155440 155440 155440 155440 1554…
31 …rcu-torture:--- End of test: SUCCESS: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_n…
36 printk() usa KERN_ALERT, dunque i messaggi dovrebbero essere ben visibili. ;-)
44 * "rtc": L'indirizzo in esadecimale della struttura attualmente visibile dai
51 mettere in "rtc" è vuota. Questa condizione è importante perché potrebbe
52 illuderti che RCU stia funzionando mentre invece non è il caso. :-/
70 * "rtbke": rcutorture è stato capace di creare dei kthread real-time per forzare
75 priorità real-time al livello 1. Il valore dovrebbe essere zero.
94 passata per (RCU_TORTURE_PIPE_LEN-2) periodi di grazia.
98 ;-)
106 * "Free-Block Circulation": il numero di strutture *torture* che hanno raggiunto
118 …srcud-torture: Tree SRCU per-CPU(idx=0): 0(35,-21) 1(-4,24) 2(1,1) 3(-26,20) 4(28,-47) 5(-9,4) 6(-…
121 *Tree SRCU*, usando un'allocazione dinamica di srcu_struct (dunque "srcud-"
122 piuttosto che "srcu-"). I numeri fra parentesi sono i valori del "vecchio"
137 #!/bin/sh
149 RCU, tuttavia ci sono stati problemi con CPU-hotplug.
161 tools/testing/selftests/rcutorture/bin/kvm.sh per le architetture x86, arm64 e
170 kvm.sh l'argomento --cpus. Per esempio, su un sistema a 64 processori, "--cpus
174 kernel). L'argomento "--dryrun sched" non eseguirà verifiche, piuttosto vi
176 per capire quanti processori riservare per le verifiche in --cpus.
179 per una modifica a Tree SRCU potete eseguire gli scenari SRCU-N e SRCU-P. Per
180 farlo usate l'argomento --configs di kvm.sh in questo modo: "--configs 'SRCU-N
181 SRCU-P'". Su grandi sistemi si possono eseguire più copie degli stessi scenari,
185 kvm.sh --cpus 448 --configs '5*CFLIST'
190 kvm.sh --cpus 448 --configs '56*TREE04'
194 kvm.sh --cpus 448 --configs '28*TREE03 28*TREE04'
197 l'argomento --memory, che di base assume il valore 512M. Per poter usare valori
198 piccoli dovrete disabilitare le verifiche *callback-flooding* usando il
199 parametro --bootargs che vedremo in seguito.
202 usare il parametro --kconfig, per esempio, ``--kconfig
203 'CONFIG_RCU_EQS_DEBUG=y'``. In aggiunta, ci sono i parametri --gdb, --kasan, and
204 kcsan. Da notare che --gdb vi limiterà all'uso di un solo scenario per
205 esecuzione di kvm.sh e richiede di avere anche un'altra finestra aperta dalla
210 modifiche del codice RCU CPU stall-warning, usate ``bootargs
213 la disabilitazione delle verifiche *callback-flooding*::
215 kvm.sh --cpus 448 --configs '56*TREE04' --memory 128M \
216 --bootargs 'rcutorture.fwd_progress=0'
219 Questo si ottiene col parametro --buildonly.
221 Il parametro --duration sovrascrive quello di base di 30 minuti. Per esempio,
222 con ``--duration 2d`` l'esecuzione sarà di due giorni, ``--duraction 5min`` di
223 cinque minuti, e ``--duration 45s`` di 45 secondi. L'ultimo può essere utile per
226 Infine, il parametro --trust-make permette ad ogni nuova compilazione del kernel
228 parametro --trust-make, i vostri file di *tag* potrebbero essere distrutti.
231 dello programma kvm.sh.
234 all'esecuzione verranno elencati alla fine fra i risultati di kvm.sh (che vi
238 di queste cartelle può essere fornita a kvm-find-errors.sh per estrarne gli
241 tools/testing/selftests/rcutorture/bin/kvm-find-errors.sh \
242 tools/testing/selftests/rcutorture/res/2020.01.20-15.54.23
246 principale (2020.01.20-15.54.23 nell'esempio precedente), mentre quelli
249 di una volta (come abbiamo visto con "--configs '56*TREE04'"), allora dalla
281 SRCU-N ------- 804233 GPs (148.932/s) [srcu: g10008272 f0x0 ]
282 SRCU-P ------- 202320 GPs (37.4667/s) [srcud: g1809476 f0x0 ]
283 SRCU-t ------- 1122086 GPs (207.794/s) [srcu: g0 f0x0 ]
284 SRCU-u ------- 1111285 GPs (205.794/s) [srcud: g1 f0x0 ]
285 TASKS01 ------- 19666 GPs (3.64185/s) [tasks: g0 f0x0 ]
286 TASKS02 ------- 20541 GPs (3.80389/s) [tasks: g0 f0x0 ]
287 TASKS03 ------- 19416 GPs (3.59556/s) [tasks: g0 f0x0 ]
288 TINY01 ------- 836134 GPs (154.84/s) [rcu: g0 f0x0 ] n_max_cbs: 34198
289 TINY02 ------- 850371 GPs (157.476/s) [rcu: g0 f0x0 ] n_max_cbs: 2631
290 TREE01 ------- 162625 GPs (30.1157/s) [rcu: g1124169 f0x0 ]
291 TREE02 ------- 333003 GPs (61.6672/s) [rcu: g2647753 f0x0 ] n_max_cbs: 35844
292 TREE03 ------- 306623 GPs (56.782/s) [rcu: g2975325 f0x0 ] n_max_cbs: 1496497
294 TREE04 ------- 246149 GPs (45.5831/s) [rcu: g1695737 f0x0 ] n_max_cbs: 434961
295 TREE05 ------- 314603 GPs (58.2598/s) [rcu: g2257741 f0x2 ] n_max_cbs: 193997
296 TREE07 ------- 167347 GPs (30.9902/s) [rcu: g1079021 f0x0 ] n_max_cbs: 478732
298 TREE09 ------- 752238 GPs (139.303/s) [rcu: g13075057 f0x0 ] n_max_cbs: 99011
304 Potreste usare kvm.sh, tuttavia questo ricompilerebbe il kernel ad ogni
309 Per questo motivo esiste kvm-again.sh.
311 Immaginate che un'esecuzione precedente di kvm.sh abbia lasciato i suoi
314 tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
318 kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28
320 Alcuni dei parametri originali di kvm.sh possono essere sovrascritti, in
321 particolare --duration e --bootargs. Per esempio::
323 kvm-again.sh tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28 \
324 --duration 45s
332 Sebbene kvm.sh sia utile, le sue verifiche sono limitate ad un singolo sistema.
334 (diciamo) 5 istanze di kvm.sh su altrettanti sistemi, ma questo avvierebbe
339 Per questo esiste kvm-remote.sh.
348 kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
349 --cpus 64 --duration 8h --configs "5*CFLIST"
354 e stampati. La maggior parte dei parametri di kvm.sh possono essere usati con
355 kvm-remote.sh, tuttavia la lista dei sistemi deve venire sempre per prima.
357 L'argomento di kvm.sh ``--dryrun scenarios`` può essere utile per scoprire
361 per kvm.sh::
363 kvm-remote.sh "system0 system1 system2 system3 system4 system5" \
364 tools/testing/selftests/rcutorture/res/2022.11.03-11.26.28-remote \
365 --duration 24h
367 In questo caso, la maggior parte dei parametri di kvm-again.sh possono essere