:: Instant WebKiosk, a browser-only Linux operating system ::
O non è che voglia fare il bastian contrario eh, però, guardando quello che fa il codice userspace:
Questo sarà quello che release_agent farà, ossia rimuove il gruppo ormai vuoto una volta uscitocodice://Crea la directory per poi... mkdir -p /dev/cgroup/cpu //...montare la gerarchia cgroup mount -t cgroup cgroup /dev/cgroup/cpu -o cpu //Crea un nuovo gruppo nella gerarchia mkdir -m 0777 /dev/cgroup/cpu/user //Attiva notify_on_release, ossia quando l'ultimo processo del gruppo termina, esegue release_agent echo "1" > /dev/cgroup/cpu/user/notify_on_release //Dice cosa eseguire come release_agent echo "/usr/local/sbin/cgroup_clean" > /dev/cgroup/cpu/release_agent
Il resto del codice viene eseguito quando viene eseguito un terminale perchè sta in .bashrccodice:#!/bin/sh rmdir /dev/cgroup/cpu/$1
Morale, se fai partire tot processi concorrenti da questo terminale, la patch ha l'effetto voluto, altrimenti no. Fra l'altro, l'effetto di tutto questo è semplicemente che anzichè avere n processi aggressivi sulla cpu schedulati uno alla volta, e quindi avere meno risorse per tutte il sistema in mddo più visibile, lo scheduler vede questi processi in gruppo e li tratta in modo diverso rilasciando più spesso la cpu per i processi che non fanno parte del gruppo.codice://Controlla se esiste il prompt (non ha nulla a che vedere con quello che si sta facendo qui, è prassi per evitare problemi) if [ "$PS1" ] ; then //Crea un gruppo per il processo in corso che è il terminale, usando il PID come identificatore mkdir -m 0700 /dev/cgroup/cpu/user/$$ //Inserisce il processo corrente (sempre il terminale appena partito) nel gruppo, del gruppo faranno parte questo processo e tutti quello da questo avviati echo $$ > /dev/cgroup/cpu/user/$$/tasks fi
Morale, se usi il tuo pc normalmente, leggendo email, sentendo musica, guardando film, tutto questo non ha effetto su di te.
Se hai software cpu intensive tipo rendering immagini fatto da software interattivi tipo gimp, etc, nessun effetto.
Se mentre fai altro compili codice lanciando n processi da terminale, vedi il film meglio e riesci a usare il pc nel mentre.
Questo non vuol dire che il discorso in seguito non possa essere esteso ad altro, ma anche la patch del kernel relativa a questo argomento e aggiunta nel 2.6.38 riguarda solo il caso qui descritto.
Come nota finale, io le cose preferisco cercare di capirle e vedere come funzionano piuttosto che accettarle passivamente.
The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.
Unico neo della dissertazione: che anche l'ambiente grafico viene lanciato su un terminale virtuale...
Ergo le conclusioni che puoi immaginare.
Ma la domanda nasce spontanea: l'hai testato? Come mai Torvalds si prende la briga di lodare apertamente la kernel patch (che poi non esegue altro che quanto fa tale codice in user space) ?
:: Instant WebKiosk, a browser-only Linux operating system ::
L'ambiente grafico viene lanciato da terminale ma gli altri processi nell'ambiente grafico no e non ereditano il tty di xorg. E se anche lo facessoro (ma non lo fanno) la soluzione userspace proposta funziona per l'utente che lancia bash e non per root. La patch fa quello che dice Torvalds è chi scrive gli articoli come quelli linkati che non ha capito qual'è il punto della patch e in quali casi migliora i tempi di risposta in ambiente desktop.Originariamente inviato da emmebì
Unico neo della dissertazione: che anche l'ambiente grafico viene lanciato su un terminale virtuale...
Ergo le conclusioni che puoi immaginare.
Ma la domanda nasce spontanea: l'hai testato? Come mai Torvalds si prende la briga di lodare apertamente la kernel patch (che poi non esegue altro che quanto fa tale codice in user space) ?
Comunque, citando dalla patch ( http://marc.info/?l=linux-kernel&m=128978361700898&w=2 )
This option optimizes the scheduler for common desktop workloads by
automatically creating and populating task groups. This separation
of workloads isolates aggressive CPU burners (like build jobs) from
desktop applications. Task group autogeneration is currently based
upon task tty association.A recurring complaint from CFS users is that parallel kbuild has a negative
impact on desktop interactivity. This patch implements an idea from Linus,
to automatically create task groups. This patch only implements Linus' per
tty task group suggestion, and only for fair class tasks, but leaves the way
open for enhancement.
The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.
Leggendo i vari post mi sono leggermente perso (non ho una grande conoscenza tecnica del mondo Linux), potreste spiegarmi cosa intendete dire per tty?
i terminaliOriginariamente inviato da Mayfair
Leggendo i vari post mi sono leggermente perso (non ho una grande conoscenza tecnica del mondo Linux), potreste spiegarmi cosa intendete dire per tty?
The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.
@alexmaz,
- Vedendola così come tu dici, la patch dovrebbe migliorare i tempi di risposta dei thread di compilazione l'uno sull'altro e non avere effetto anche -fuori- da quel task. E mi pare non sia così. Infatti la citazione è correttissima.
- Il task di compilazione è un mero esempio, prova a fare un test su copia intensiva di file.
- L'esempio portato è in user space ma la kernel patch no. E chiaramente è applicabile anche a root.
:: Instant WebKiosk, a browser-only Linux operating system ::
No, migliora i tempi di risposta di tutto perchè cambia il comportamento dello scheduler nei confronti di quei processi in gruppo.Originariamente inviato da emmebì
@alexmaz,
- Vedendola così come tu dici, la patch dovrebbe migliorare i tempi di risposta dei thread di compilazione l'uno sull'altro e non avere effetto anche -fuori- da quel task. E mi pare non sia così. Infatti la citazione è correttissima.
- Il task di compilazione è un mero esempio, prova a fare un test su copia intensiva di file.
- L'esempio portato è in user space ma la kernel patch no. E chiaramente è applicabile anche a root.
Si la versione non user space è systemwide ma rimane il problema del grouping per tty, quindi si applica agli stessi casi. Infatti è stata proposta come primo step proprio per quei casi.
The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.
E' possibile lanciare più processi da terminale contemporaneamente es. browser e lettore multimediale? In questo caso la patch funzionerebbe?
Mah in teoria si, in pratica ha senso per processi cpu intensive e che siano almeno in un certo numero, bisognerebbe provare ma non ha cmq molto senso. Il punto è che per un utilizzo dekstop comune ossia navigare, scrivere qualcosa e magari guardare un film contemporaneamente, non cambia nulla perchè nessuno di questi è un task particolarmente stressante per la cpu.
The individual has always had to struggle to keep from being overwhelmed by the tribe. If you try it, you will be lonely often, and sometimes frightened. But no price is too high to pay for the privilege of owning yourself.
Permessi di invio
Rispondi quotando