Increible pero real, y son excelentes noticias realmente. El scheduler creador por Con Kolivas, que yo vengo usando hace mucho, el cual formaba parte del sector "hacker medio" o usuarios de Arch, podría hacerse realidad en Linux 3.16.
Aparentemente se esta mejorando el parche, añadiendole funciones (el mismo al usarlo no se usan cgroups y tiene algunos problemas), para que se incorpore como uno mas, junto a NOOP, DEADLINE y CFQ en Linux 3.16
Esto es una excelente noticia, porque el proyecto de linux-rt, (real time), hace rato que lo veo en la nada misma, y cuando probé, debo decir que rinde mas el parche de Con Kolivas que real time de Linux.
Esto supondria no solo un salto en velocidad increible para desktops (no se si conviene en laptops, porque tambien consume mas CPU y por tanto mas bateria), sino que hablando de dispositivos moviles, como celulares, tablets, etc, daría una clarisima ventaja sobre otras plataformas, incluso ya me imagino un Android usando este kernel.. mas ART la nueva maquina virtual de Google, creo que estaria a la altura de Windows Phone y iOS en rendimiento, no se si en uso de RAM, pero si en velocidad.
El que lo haya probado sabrá que los FPS de OpenGL asi como los tiempos de compilacion se ven drasticamente aumentados usando BFQ.
BFQ, significa algo como Budget Fair Queueing I/O Scheduler, y de eso se trata.
Les dejo la lista de mail para que la vean y por lo que aprecio de como le responden a Paolo, modificaciones en cgroup.c y demas, apuesto a que SI va ser incluido en Linux 3.16, solo habra que seleccionarlo en el cmdline poniendo: elevator=bfq
La verdad, excelente noticia, por cierto, hay mas noticias sobre Unity y demas pelotudeces pero prefiero las noticias mas tecnicas, no quiero que esto parezca mulinux.com
http://lkml.iu.edu/hypermail/linux/kernel/1405.3/01358.html
Aparentemente se esta mejorando el parche, añadiendole funciones (el mismo al usarlo no se usan cgroups y tiene algunos problemas), para que se incorpore como uno mas, junto a NOOP, DEADLINE y CFQ en Linux 3.16
Esto es una excelente noticia, porque el proyecto de linux-rt, (real time), hace rato que lo veo en la nada misma, y cuando probé, debo decir que rinde mas el parche de Con Kolivas que real time de Linux.
Esto supondria no solo un salto en velocidad increible para desktops (no se si conviene en laptops, porque tambien consume mas CPU y por tanto mas bateria), sino que hablando de dispositivos moviles, como celulares, tablets, etc, daría una clarisima ventaja sobre otras plataformas, incluso ya me imagino un Android usando este kernel.. mas ART la nueva maquina virtual de Google, creo que estaria a la altura de Windows Phone y iOS en rendimiento, no se si en uso de RAM, pero si en velocidad.
El que lo haya probado sabrá que los FPS de OpenGL asi como los tiempos de compilacion se ven drasticamente aumentados usando BFQ.
BFQ, significa algo como Budget Fair Queueing I/O Scheduler, y de eso se trata.
Les dejo la lista de mail para que la vean y por lo que aprecio de como le responden a Paolo, modificaciones en cgroup.c y demas, apuesto a que SI va ser incluido en Linux 3.16, solo habra que seleccionarlo en el cmdline poniendo: elevator=bfq
La verdad, excelente noticia, por cierto, hay mas noticias sobre Unity y demas pelotudeces pero prefiero las noticias mas tecnicas, no quiero que esto parezca mulinux.com
http://lkml.iu.edu/hypermail/linux/kernel/1405.3/01358.html
Y tanto que buena noticia. Aunque no sé si es efecto placebo pero en arch y en debian (liquorix kernel) noto que el escritorio es mucho más responsivo sobre todo cuando estoy copiando ficheros largos en los que con el kernel standard el sistema se queda medio congelado y en cambio con el kernel liquorix todo sigue respondiendo. Parece que tiene ventajas en multimedia también. Pero hasta donde llego el bfq es el planificador de escritura en disco I/O no el del procesador que es bfs. Pero no se si estoy equivocado y de hecho viene desactivado por defecto en el parche -ck: http://algo.ing.unimo.it/people/paolo/disk_sched/
ResponderEliminarYo usaba ambos BFQ y BFS, supongo que en BFQ meteran algo de BFS, sino... no tiene mucha gracia.
ResponderEliminarhttp://ck.kolivas.org/patches/bfs/
Yo metia ese y el BFQ, los dos, es que... es como que sino no tiene gracia alguna jajaa. La idea es un kernel totalmente real time no solo en la seccion I/O
Y es buena idea usarlo en un SSD?
ResponderEliminarSi, porque no?. No cambia lo que es trim si a eso apuntas
ResponderEliminarno por el trim, por el scheduller. https://wiki.archlinux.org/index.php/Solid_State_Drives#I.2FO_Scheduler
ResponderEliminarAhi comenta que mejor usar NOOP o deadline frente a CFQ usando SSD, no dice nada sobre BFQ, asi que ... no debe haber problema, sin mencionar que he visto muchos arch users usando el kernel -ck que posee el parche de kolivas, el de bfq en discos ssd sin problemas.
ResponderEliminarEso quería saber. Calculo llegado el momento agregarán info a la wiki.
ResponderEliminarComo es Archwiki, asumo que si jaja
ResponderEliminar