2012-04-19 12 views
9

Ho un'applicazione che periodicamente (dopo ogni 1 o 2 secondi) prende i punti di controllo a forche. Quindi il checkpoint è un fork del processo originale che rimane inattivo fino a quando non viene chiesto di iniziare quando si verifica qualche errore nel processo originale.Costo di una trappola di errore di una pagina

Ora la mia domanda è quanto sia costoso il meccanismo di copia su scrittura della forcella. Quanto costa il costo di un trap di errore di pagina che si verificherà ogni volta che il processo originale scrive su una pagina di memoria (la prima volta dopo aver preso un checkpoint), poiché il meccanismo di copia su scrittura assicurerà che questo dia al processo originale un diversa pagina fisica rispetto al checkpoint.

A mio parere, il sovraccarico del trap di errore di pagina potrebbe essere piuttosto elevato quando si verifica un'interruzione, ci spostiamo dal terreno dello spazio utente allo spazio dello spazio del kernel e quindi dal kernel allo spazio utente. Quanti cicli della CPU posso perdere da una trappola di questo tipo. Supponiamo che la RAM sia abbastanza grande e non abbiamo mai bisogno di scambiare sul disco rigido.

Beh, so che è difficile immaginare uno schema di checkpoint più efficiente di questo e quindi si potrebbe dire perché mi preoccupo per il sovraccarico dell'errore di page trap, ma sto chiedendo solo di avere un'idea di quanto sarà il costo lì per questo schema.

+0

Dipende molto dai modelli di accesso ai dati dell'applicazione. Prova a confrontare i tempi di esecuzione con e senza punti di controllo per vedere come i checkpoint influiscono sul tempo di esecuzione. –

+1

Non riesco a vedere l'utilità di questo checkpoint. Dopo il fork(), genitore e figlio sono identici. A seguito dell'uscita genitore() s, il bambino probabilmente fa riferimento esattamente alle stesse pagine fisiche, poiché il genitore ha abbandonato i suoi riferimenti (lo stato COW per le pagine può essere sostituito in "allegato" per il processo figlio, poiché uno stato COW con solo il processo di referenziamento non ha senso) – wildplasser

+0

wildplasser, la necessità di checkpoint è di evitare il riavvio dell'applicazione. Potrebbe essere ripreso da uno stato precedentemente salvato a.k.un punto di controllo. – pythonic

risposta

10

È possibile eseguire autonomamente i calcoli matematici per un'ipotesi istruita. Supponendo che non l'accesso al disco (~ 10 miliardi di cicli), si deve tenere conto di

  • 160 cicli per la trappola e ritorno (circa, su x86_64)
  • controlli di validità, di quote, la contabilità, e quant'altro (sconosciuto, probabilmente poche centinaia a un migliaio di cicli)
  • allineati memcpy di 4096 byte, qualcosa intorno a 500-800 cicli
  • TLB invalidazione (aggiunge 10-100 cicli al primo accesso)
  • uno sfratto di altri dati memorizzati nella cache o un errore di cache garantito (80-400 cicli) a seconda dell'implementazione di memcpy. Importa molto sul tuo modello di accesso se uno o l'altro è meglio.

Quindi, tutto sommato, stiamo parlando di qualcosa intorno a 2000 cicli, con alcuni degli effetti (ad esempio TLB e gli effetti della cache) di essere sparsi e non immediatamente visibile. Omondi e Sedukhin riportarono 1700 cicli su P-III nel 2003, il che è coerente con questa stima.

Si noti che se la pagina non è mai stata scritta in precedenza, le cose sono leggermente diverse secondo un commento di L. Torvalds nel 2000. Una mancata copia su scrittura su una pagina zero tira un'altra pagina zero dal pool e non copia zero. Ma è anche un errore di cache garantito.

+0

Molto informativo. Grazie! – pythonic

Problemi correlati