Potrete scegliere tra due modalità d'esame. Quale che sia la modalità d'esame che sceglierete, avrete il mio aiuto per ogni passaggio per il quale avrete bisogno di aiuto.

1. Esame pratico

L'esame sarà una naturale espressione di quanto appreso nel corso, ossia consisterà in:
- cercare di risolvere un piccolo problema del block layer;
- trasformare la propria soluzione in un 'pacchetto' pronto per la distribuzione, ossia nel preparare una o più patch contenenti tale soluzione;
- distribuire e proporre tale contributo attraverso il canale appropriato, ossia sottomettere in modo opportuno tale/tali patch alla comunità.

Fornire un contributo reale di questo tipo, per quanto piccolo, ha degli aspetti impegnativi:
- dover fronteggiare una complessità maggiore rispetto alla realizzazione di un progetto giocattolo, con sole finalità didattiche;
- non avere a disposizione un manuale di riferimento in cui trovare la risposta per qualsiasi dubbio;
- con molta probabilità, dovere chiedere aiuto a me di tanto in tanto; in merito, come ho già scritto, avrete totale disponibilità da parte mia.

Date queste difficoltà, non sarà necessario un lavoro perfetto per ottenere il voto massimo.

Infine, per darvi un'idea più precisa dei contributi che realizzerete per l'esame, e dei tempi necessari per la loro preparazione, eccovi alcuni dei contributi realizzati dagli studenti della scorsa edizione del corso, contributi entrati tutti nel kernel Linux.

Patch - Autore/Firmatario - Tempo totale speso dall'autore per preparare l'esame e la patch
"block, bfq: fix occurrences of request finish method's old name" - Chiara Bruschi - 15 giorni
"block, bfq: put async queues for root bfq groups too" - Davide Ferrari - 15 giorni
"block, bfq: add requeue-request hook" - Serena Ziviani - 20 giorni (scelto lavoro più impegnativo)
"block, bfq: remove the removal of 'next' rq in bfq_requests_merged" e "block, bfq: remove wrong lock in bfq_requests_merged" - Filippo Muzzini - 15 giorni
"block, bfq: prevent soft_rt_next_start from being stuck at infinity" e "block, bfq: increase weight-raising duration for interactive apps" - Davide Sapienza - 21 giorni

2. Esame compilativo

L'esame consiste nell'analizzare, e descrivere in una relazione di due o tre pagine, il funzionamento di un componente del block layer. Decideremo assieme quale componente.

L'esame di tipo compilativo ha un livello di difficoltà un po' più basso dell'esame pratico. Di conseguenza, a parità di qualità del lavoro svolto, con l'esame compilativo potrete aspirare ad un voto un pochino più basso rispetto al voto che avreste ottenuto con l'esame pratico (probabilmente nell'ordine di tre punti). In particolare, per raggiungere il voto massimo sarà necessario un lavoro molto buono.

Il tempo necessario per preparare questo tipo di esame è probabilmente di una settimana.

-------------------------------------------------------------------------------

Ecco un elenco dei possibili compiti per i quali creare opportune patch (chiedete senza alcun problema a me per ogni dettaglio):

. Ripetere test velocità compilazione del kernel con bfq, perche' uno dei maintainer dello storage (Bart Van Asche) lamenta dei rallentamenti. Se la perdita' di velocità' c'e', cercare la causa


. Portare dentro bfq, prendendola da mq-deadline, la gestione degli zoned block device

. Ripetere i test di throughput che vanno male per bfq nei report pubblicati periodicamente su Phoronix

. Effettuare test di latenza, ed in particolare, implementare patch che fa preemption in base a rapporto pesi, proprio per migliorare la latenza

. Rifare lo script di misura degli iops massimi supportati da uno scheduler (IOSpeed), usando iostat al posto dell'output di fio, e prendendo le misure durante il periodo stazionario

. Ripetere i test della suite mmtests sui quali Suse riporta che bfq ancora va peggio di cfq

. Portare a bfq-mq e, e se ha senso, anche a bfq-sq, uno o più commit esistenti per bfq mainline ma non ancora esistenti per bfq-mq e bfq-sq.

Per controllare rapidamente quali sono tali commit, confrontare l'output dei seguenti due comandi:
git log --oneline master block/bfq*
git log --oneline bfq-mq block/bfq*
Poi, per controllare i commit più in dettaglio, usare i comandi di sopra senza --oneline.

. Portare i commit per mq-deadline a bfq, bfq-mq e bfq-sq

. Portare i commit per kyber a bfq, bfq-mq e bfq-sq

. Tentare fix di problemi riscontrati durante la prova di bfq sul proprio PC

. Controllare se si può fare senza lock la free di cui al commento seguente:
	/*
	 * XXX Not yet freeing without lock held, to avoid an
	 * inconsistency with respect to the lock-protected invocation
	 * of blk_mq_sched_try_insert_merge in bfq_bio_merge. Waiting
	 * for clarifications from Jens.
	 */

. Portare per bfq-mq i cambiamenti per bfq

. Fare uno script per trasformare bfq in bfq-mq

. Migliorare i log di bfq:
- controllare quanto overhead hanno quando il tracing è spento
- rendere logging in bfq efficiente come in bfq-mq e bfq-sq, portando la patch di Lee per spegnere il tracing
- stampare nome funzione attraverso macro
- far stampare abbreviazione motivo al posto di numero nel messaggio di expire

. Collaudare Kyber attraverso lo script IOSpeed, con e senza maschera per il pinning dei processi. Se kyber va più forte grazie al bilanciamento tra le code, pensare di integrare questa feature dentro bfq

. "sembra proprio il dmcrypt_write che congela un po' le cose, provando a cambiare i vm.dirty_background_ratio e vm.dirty_ratio a 0, le cose migliorano, solo che a scompattare un tar.gz come il kernel ci mette un quarto d'ora...; probabilmente il problema è in quell'intorno...a questo punto il bfq sarebbe sopra il dmcrypt. Hai mai fatto delle prove con quelle condizioni?"

. Impedire merge di code se appartengono a gruppi distinti