Tasklets:
- sono vecchi (circa 2,3 credo)
- hanno una semplice API semplice,
- sono progettati per bassa latenza
- non riesce a dormire (run atomicamente nel contesto IRQ morbido e sono garantiti per non funzionare mai su più di una CPU di un determinato processore, per un determinato tasklet)
code di lavoro:
- sono più recenti (introdotto nel 2.5)
- hanno un'API flessibile (più opzioni/bandiere supportati)
- sono progettati per una maggiore latenza
- può dormire
La linea di fondo è: utilizzare le attività per attività atomiche a priorità alta ea bassa latenza che devono ancora essere eseguite al di fuori del difficile contesto IRQ.
È possibile controllare un certo livello di priorità con tasklets utilizzando tasklet_hi_enable/tasklet_hi_schedule (invece dei rispettivi no- _hi versioni). Da this IBM page:
Il programma con priorità normale viene eseguita tramite la softirq TASKLET_SOFTIRQ-livello, in cui la massima priorità è attraverso il softirq livello HI_SOFTIRQ.
...
Tasklets dal vettore ad alta priorità sono servite prima, seguita da quelle sul vettore normale. Nota che ogni CPU mantiene i propri vettori softirq normali e ad alta priorità.
Con code di lavoro, durante la creazione di uno, si utilizzerà alloc_workqueue (create_workqueue è deprecato) e can pass a flag a chiedere maggiore priorità:
WQ_HIGHPRI:
Gli elementi di lavoro di un WQ highpri sono in coda al pool di thread highpri di gcwq di destinazione.I pool di thread HighPri vengono offerti dai thread di lavoro con un livello elevato elevato.
Si noti che i pool di thread normali e highpri non interagiscono con altri . Ciascuno mantiene il suo pool separato di lavoratori e implementa la gestione della concorrenza tra i suoi dipendenti.
Non posso rispondere a tutte le vostre domande, ma spero che questo aiuti comunque.