Perché gli scheduler BFQ e BFS non sono inclusi nel kernel ufficiale di Ubuntu?

Ieri ho letto un articolo su come accelerare Ubuntu. Un suggerimento nell'articolo era la sostituzione dello scheduler I / O predefinito con BFQ , che secondo l'articolo è ottimizzato per le prestazioni interattive.

Un articolo simile evidenzia i vantaggi in termini di prestazioni del desktop quando si utilizza lo scheduler di processo BFS .

Entrambi gli scheduler sono inclusi in numerosi patchset e kernel alternativi noti per aumentare l'interattività e le prestazioni del desktop (ad esempio linux-pf , liquorix-kernel e linux-ck ).

Quindi la mia domanda è : dato che Ubuntu si impegna per una straordinaria esperienza desktop, come mai le build non server del sistema operativo non arrivano con questi programmatori quando si sono dimostrati migliori in termini di prestazioni interattive?

Ulteriori informazioni sui due programmatori sono disponibili qui:

• BFQ : http://algo.ing.unimo.it/people/paolo/disk_sched/
• BFS : http://ck.kolivas.org/patches/bfs/bfs-faq.txt

Risposta rapida :

1. Entrambi gli scheduler non funzionano affatto o funzionano bene per tutte le piattaforme supportate di Linux (frequenza, architettura, consumo di risorse, ...)
2. Sembra che Torvalds semplicemente non voglia supportare più di un programmatore

Spiegazioni:

Poiché gli scheduler sono solo iniziative (ovvero non supportate dal kernel), il solo fatto di includerlo significherebbe focalizzare le persone su quegli scheduler (patch di sicurezza, patch di manutenzione, accelerare l'adattamento alle nuove versioni del kernel, ...). Significa investimenti finanziari per un progetto che non è ancora sicuro della sua esistenza in futuro.

Sono ancora abbastanza giovani. Il miglior esempio è quello che viene spiegato nelle FAQ di BFS in "Quanto è scalabile?".

Dietro le linee di questa parte ci dice che BFS ha problemi di prestazioni quando si ha molta CPU logica. Questo singolo punto viene eliminato per server e PC di fascia alta (viene indicato il numero di 16, quindi un semplice server da 1000 USD avrebbe problemi di prestazioni con questo). Quindi si esclude Ubuntu Server da questa patch, si escludono anche configurazioni di CPU bi fisiche che ora raggiungono facilmente questo numero.

Ubuntu non può raggiungere le masse se utilizza un altro programmatore. La scalabilità vince sulle prestazioni.

Come sempre, con molti "se" ...:

• Se ogni utente di Ubuntu è un utente desktop
• Se ogni macchina di ciascun utente Ubuntu è il pc corretto per gli scheduler

In effetti l'approccio migliore è quello attuale: lascia che l'utente applichi gli scheduler che desidera se ha l'hardware e se è interessato ad esso.

Applicarlo potrebbe funzionare meglio per alcuni nel tempo (perché, come ho già detto, la scalabilità è un grosso problema e il futuro aumenterà il numero di processori). Ma darà seri problemi agli altri.

Fonti extra:

Il link potrebbe non rimanere per sempre, ecco un articolo che ho trovato su BFS su h-online . È il più ufficiale che ho trovato. Tuttavia, se vai su Google, potresti trovare la vera dichiarazione. Penso che potrebbe essere su kerneltrap.

Vedi il terzo paragrafo del titolo fenice dell'articolo. Lo citerò qui nel caso in cui il link si spenga:

Al momento, l'integrazione di BFS nel ramo di sviluppo principale di Linux sembra molto improbabile, poiché Linus Torvalds ha già chiarito che non vuole mantenere più programmatori. Inoltre, i distributori di Linux tendono a preferire una singola immagine del kernel che raggiunge prestazioni ottimali su un'ampia varietà di sistemi senza richiedere una configurazione speciale. È possibile che gli sviluppatori CFS miglioreranno il loro programmatore nelle aree coperte da BFS, un vantaggio per la comunità di utenti.

Linus Torvalds Discussione al riguardo.