vantaggio della tasklet nell'applicazione dello spazio utente

Question

Ho qualche dubbio con la metà inferiore. Qui considero solo i tasklet.Inoltre, considero solo il kernel non prerilasciabile.

Supponiamo di considerare un driver Ethernet in cui l'elaborazione dell'interruzione RX sta eseguendo circa 10 chiamate di funzioni (cattiva programmazione :))

Ora, guardando la prospettiva delle prestazioni se 9 chiamate di funzione possono essere spostate in un tasklet e solo 1 deve essere chiamata nella gestione degli interrupt, posso davvero ottenere buone prestazioni in un'applicazione di lettura TCP.

O in altre parole, quando si passa all'applicazione dello spazio utente verranno richiamate tutte le 9 chiamate di funzione per i tasklet pianificati, in effetti l'applicazione dello spazio utente sarà in grado di ottenere il pacchetto con i dati solo dopo che "tutti i tasklet pianificati" sono stati completato ?corretto?

Capisco che avendo la metà inferiore, stiamo abilitando tutti gli interrupt..ma ho dei dubbi sul fatto che l'applicazione che fa affidamento sull'interruzione guadagni effettivamente qualcosa avendo tutte le 10 funzioni nel gestore dell'interruzione stesso o nella metà inferiore.

In breve, avendo tasklet ottengo un miglioramento delle prestazioni nell'applicazione dello spazio utente, qui?

Answer 1

Dato tasklets non sono in coda, ma in programma, vale a dire diversi interrupt di processo la pubblicazione della stessa tasklet potrebbe comportare una singola funzione invocazione tasklet, si sarebbe in grado di salvare fino al 90% del trattamento in condizioni di estrema casi.

D'altra parte c'è già un morbido IRQ ad alta priorità per la net-rx.

Answer 2

Nella mia esperienza su macchine veloci, movimento di lavoro dal gestore per la tasklet non fa funzionare la macchina più veloce. Ho macro aggiunto nel gestore che può trasformare la mia schedule_tasklet () chiamata in una chiamata alla funzione tasklet in sé, ed è facile da punto di riferimento in entrambe le direzioni e vedere la differenza.

Ma è importante che i gestori di interrupt finire in fretta. Come accennato Nikolai, si potrebbe beneficiare se il dispositivo piace di interrompere un sacco, ma la maggior parte dei dispositivi a banda larga avere l'hardware mitigazione interrupt che rende questo un problema meno grave.

utilizzando tasklets è il modo in cui kernel nucleo gente sta andando a fare le cose, quindi tutto il resto è uguale, è probabilmente meglio a seguire il loro esempio, soprattutto se si vuole mai vedere il driver accettato nel kernel mainline.

Vorrei anche notare che chiamando un sacco di funzioni non è necessariamente una cattiva pratica; moderni predizione delle diramazioni possono fare ramo pesante codice run altrettanto velocemente come codice non-branch-pesante. Molto più importante a mio parere sono i potenziali effetti della cache di avere a che fare metà del lavoro oggi, e quindi la metà in un secondo momento.

Answer 3

Un tasklet non viene eseguito nel contesto del processo utente.Se il tuo ISR pianifica un tasklet, verrà eseguito immediatamente dopo il completamento dell'ISR, ma con gli interrupt abilitati.Il vantaggio di ciò è che l'elaborazione dei pacchetti non impedisce ulteriori interruzioni.

Nel tuo esempio TCP, l'hardware trasmette il pacchetto allo stack di rete e il tuo driver è pronto: lo stack di rete gestisce il risveglio del processo, ecc.quindi non c'è davvero alcun modo per il driver dell'hw di essere eseguito nel contesto del processo del destinatario dei dati, perché l'hw non sa nemmeno chi sia.