2012-12-19 10 views
12

Nei processori che supportano il contatore timestamp (TSC) Linux fornisce l'opzione del timer ad alta risoluzione utilizzando TSC. Da quanto ho capito, TSC è un registro che può essere letto ma non offre l'opzione di interrompere la CPU a una velocità configurata. Quindi, per la generazione di interrupt del timer in Linux deve ancora fare affidamento su I/O APIC (su x86) con valore HZ tipicamente impostato su 1000 o 250.L'utilizzo di TSC come sorgente di clock migliora il timer e la granularità della pianificazione?

Anche se TSC fornisce timestamp a microsecondi granularità la granularità del timer/pianificazione sarà ancora a 4ms o 1ms a seconda del valore HZ. Questa comprensione è corretta? O c'è un'opzione per migliorare la granularità del timer usando il TSC?

+0

Se si desidera ottenere alcuni eventi timer molto spesso con grande precisione, si tratta di un compito per sistemi real-time. Un comportamento approssimativamente simile può essere ottenuto utilizzando meccanismi in tempo reale del kernel o giocando con l'affinità dei processi su sistemi multi-core (quindi il processo che devi essere in tempo reale è pianificato per un solo core, e altri processi non possono correre su quel nucleo). –

risposta

9

Nel kernel Linux 2.6 predefinito, il PIT (Programmable Interrupt Controller) (disponibile su tutti i PC) viene utilizzato come timer di sistema [1]. PIT, come suggerisce il nome, può essere programmato (di solito, all'avvio del kernel) per interrompere la CPU a una velocità predeterminata. Questo tasso predeterminato è il valore HZ a cui fai riferimento, che è un valore compilato staticamente uguale al parametro di compilazione del kernel CONFIG_HZ. [2] Quindi, è possibile modificare CONFIG_HZ in fase di compilazione e il PIT inizierà a interrompere la CPU a tale frequenza. Tuttavia, tieni a mente che PIT è guidato internamente da un clock di circa 1.193 MHz, quindi impostare CONFIG_HZ su un valore superiore a questo valore non sarà una grande idea. E come indicato in [3]

il timer dell'APIC locale (Advanded Programmable Interrupt Controller) in sistemi multiprocessore è utilizzato per interprocessor sincronizzazione

e andando dalla spiegazione [1] , Credo che il suo PIT (e non l'APIC locale) sia legato al valore HZ (almeno fino al kernel 2.6).

Ora, venendo alla tua domanda, in teoria la tua idea sembra corretta. Il contatore di data e ora come APIC e PIT locali, è un'altra fonte di tempo [1]. In [4], trovi una conferma di questo.

Linux possono trarre vantaggio da questo registro per ottenere misurazioni di tempo molto più preciso di quelli forniti dal Timer programmabile Intervallo. Per fare ciò, Linux deve determinare la frequenza del segnale di clock durante l'inizializzazione del sistema. Infatti, poiché questa frequenza non è dichiarata durante la compilazione del kernel, la stessa immagine del kernel può essere eseguita sulle CPU che potrebbero spuntare a qualsiasi frequenza.

Tuttavia, ricordare che il contatore di timestamp viene incrementato ad ogni ciclo di clock della CPU. E questo ci porta alle insidiose insidie ​​associate a un contatore associato ai cicli di clock della CPU [5]. Un esempio è che le moderne CPU possono cambiare la frequenza di clock della CPU per risparmiare energia e questo potrebbe influire sul valore memorizzato nel contatore di data e ora. Se ciò accade, puoi stimare l'effetto che può avere sulle tue misurazioni del tempo. Inoltre, un kernel assolutamente inattivo può chiamare l'istruzione HALT che arresta del tutto il processore fino a quando non viene ricevuto un interrupt esterno. Per tutto questo tempo, il TSC non sarebbe mai stato incrementato e avresti perso alcuni "incrementi" preziosi, che altrimenti avrebbero reso le tue misurazioni più precise. In breve, la gestione del TSC è un problema difficile, non particolarmente utilizzabile come interrupt programmabile.

  1. Robert Love, LKD --3rd Edition.(Capitolo 11)
  2. http://lxr.linux.no/linux+v2.6.31/arch/x86/include/asm/param.h#L5
  3. http://www.6test.edu.cn/~lujx/linux_networking/0131777203_ch02lev1sec7.html
  4. http://www.makelinux.net/books/ulk3/understandlk-CHP-6-SECT-1
  5. http://lwn.net/Articles/209101/
+2

Ottima risposta. C'è un'ulteriore complicazione: su un sistema multi-CPU, i singoli core hanno i loro ticker, che possono o non possono essere sincronizzati, a seconda dell'architettura, del BIOS e della fase lunare. Nelle architetture che ** hanno ** orologi sincronizzati, RDTSC funziona come un * punto di sequenza *, in effetti un crawbar. Altamente sconsigliato. – wildplasser

Problemi correlati