Sebbene Linus Torvalds avesse menzionato a metà giugno che intendeva integrare sched_ext per Linux 6.11 come entusiasmante codice di scheduling estensibile, questo alla fine non è avvenuto… Il kernel Linux 6.11-rc1 è stato appena rilasciato per chiudere la finestra di unione di Linux 6.11 e il il codice non è stato estratto schedule_ext.
Molti sviluppatori del kernel sono stati entusiasti di sched_ext perché rende più semplice e veloce l'iterazione delle modifiche alla pianificazione del kernel, il prototipo di un nuovo comportamento di pianificazione e così via. Linus Torvalds ha espresso il mese scorso che non voleva continuare a ritardare la sua integrazione e che il suo piano era di integrarlo con Linux 6.11.
Su richiesta, il 15 luglio, non appena si è aperta la finestra di integrazione di Linux 6.11, Tejun Heo ha presentato richiesta pull sched_ext. Sched_ext è cresciuto fino a raggiungere circa 14.000 righe di nuovo codice, inclusi test e relativa infrastruttura.
Ma da allora Alcuni problemi di codice Miglioramento notato. Poi, qualche giorno fa, Qais Youssef Amido Alcune preoccupazioni:
Ho appena rivisto questo e penso che tu stia andando nella direzione sbagliata qui. Non penso che l'attuale livello di revisione sia stato sufficiente e stiamo affrettando i tempi per rilasciarlo alla versione 6.11.
Non dovremmo davvero cambiare il modo in cui funziona schedutil. Un governante dovrebbe agire in un certo modo e dobbiamo garantire la coerenza. Penso che dovresti esaminare come rendere compatibile il tuo scheduler con esso. Aggiungere hook per implementare il valore prestazionale che desidero è una ricetta per la casualità.
In generale, ho grandi preoccupazioni riguardo al caricamento di sched_ext che causa un rapporto di errore fasullo perché modifica il comportamento dello scheduler e il kernel non è affidabile durante il caricamento dello scheduler sched_ext. Come i moduli fuori dall'albero, questo dovrebbe causare inquinamento del kernel. Questo è qualcosa che avevo chiesto qualche anno fa quando Gushchin inviò la prima proposta
Come possiamo fidarci della segnalazione degli errori e del rollback quando il codice viene caricato all'esterno dell'albero che modifica in modo intrusivo il modo in cui si comporta il kernel? Questo dovrebbe essere contrassegnato come un difetto del kernel altrimenti saremo condannati a fallire nel tentativo di correggere il codice all'esterno dell'albero.
Un altro problema comune con i report di regressione è perché il codice non viene caricato a causa di cambiamenti nel modo in cui si evolve lo scheduler. Dobbiamo continuare a poter modificare liberamente il codice senza preoccuparci di uscire dal codice. Qual è la regola di regressione? Non vogliamo essere limitati dalla possibilità di apportare modifiche all'interno del kernel perché il codice esterno all'albero ora fallirà; Scaricalo o eseguilo come previsto. In che modo il codice esistente è progettato per gestire la sicurezza quando lo scheduler esterno non è più compatibile con il kernel esistente e deve *dover* riscrivere il suo codice, proprio come accade ora con i moduli fuori albero?
Ora è stato rilasciato Linux 6.11-rc1 e il codice non è stato unito. Linus Torvalds non ha commentato pubblicamente questa pull request, almeno non ancora. Sembra che alla fine saranno necessari alcuni miglioramenti a sched_ext.
Vedremo se sched_ext verrà preparato ulteriormente in tempo per la fine del ciclo del kernel Linux 6.12 quest'anno. Linux 6.12 sarà probabilmente anche il rilascio del kernel LTS (Long Term Support) di quest'anno.