Planificador del kernel de Linux: una década de procesadores desaprovechados [ENG]

Se publican los parches para el kernel de Linux que solucionan los problemas descritos en el paper “The Linux Scheduler: a Decade of Wasted Cores” (http://www.ece.ubc.ca/~sasha/papers/eurosys16-final29.pdf 365 KB), donde se describen los problemas que tiene el planificador (scheduler) del kernel Linux al desaprovechar el tiempo de proceso teniendo hilos en la cola de espera mientras hay procesadores libres.

[#3 kumo]

Cores, que no procesadores. Puede inducir a error.

[#25 Desactivado]

#3 Cierto, el título original habla de núcleos. Pero si el planificador no les asigna los hilos pendientes también se puede hablar de procesadores desaprovechados

[#24 Rubenix]

Si eso implica que todavía puede ir más rápido, entonces es una muy muy buena noticia.

Es lo bueno del código abierto, no es que sea perfecto, pero que se pueda auditar y mejorar lo hace mejor.

[#35 zeioth]

#24 Ademas es cojonudo, no solo lo ha investigado, sino que ademas ha desarrollado herramientas para ayudar a los programadores del kernel a mejorar el rendimiento. Se puede ser mas majete?

[#37 Rubenix]

#35 Ahora a esperar que Linus dé el visto bueno para integrarlo en el kernel. Mi Mint está esperando un nuevo parche.

[#5 mr_b]

#4 En teoría es el propio paper el que lo “demuestra”. Claro que ahora faltaría la revisión por pares.

[#55 jbko]

#5 Habrá que esperar al paper de verdad, por ahora pone que lo envían a un proceeding de una conferencia, los cuales suelen tener una revisión más laxa que una revista científica.

[#77 javicid]

#5 #55 Es el EuroSys de este año. Una conferencia bastante buena. En informática los journals no tienen por qué tener una revisión más dura ni tener más prestigio que muchas conferencias.

[#48 Dovlado]

#10 El problema es que el 8 tiene serios problemas en su gestión de red y el 10 se come la ram de forma absurda y misteriosa.

En términos generales el 7 rinde mucho mejor. Y te lo digo yo que usa los tres ahora mismo con hardware creciente proporcionalmente a la versión

[#63 Desactivado]

#48 mi experiencia es que con hardware antiguo y poca ram, w10 funciona mucho mejor que w7.

El mayor uso de RAM es precisamente lo que provoca la mejoría, porque usa la ram para cache y optimitzaciones que Windows 7 simplemente no hace.

Eso sin contar la compresión de memoria lo que hace que con poca ram se le saque más partido.

[#12 quatrox4]

han puesto en github un borrador del código,
no han subido los programas de test y además hay un error garrafal en el parche
missing_sched_domains_linux_4.1.patch
en un procedimiento declaran una variable y la usan en otra parte que no tiene ninguna relación,

si quieren contribuir al código libre deberían probar el código y presentar algo que ya esté bastante bien

[#38 GoDie]

#12 ¿alguien puede enlazar los insultos de linus al respecto ?

[#61 quatrox4]

#38 lo puedo decir más claro,
este código es un esquema de lo que ellos dicen que debería hacerse pero está tan mal que ni siquiera debe compilar,

De ello se pueden deducir dos cosas:
- O bien son unos incompetentes y no saben hacerlo mejor,
- O quizás esperan que alguien les pague por liberar las modificaciones que han hecho sobre un código que ellos están usando gratis.
Puede ser que ambas sean válidas,

no creo que se hayan atrevido a mandarlo a los desarrolladores del kernel porque les hubieran banneado de por vida.

Esto no es un insulto, es una suposición de lo que pasaría basada en anteriores historias de este mismo estilo.

[#49 Dovlado]

Con Kolivas, propuso unos cambios en el planificador que mejoraban mucho su rendimiento. La respuesta del acomplejado de Linus, fue echarlo del proyecto.

[#50 Desactivado]

#49 Iba bien en multimedia, no en servidor.

[#52 mr_b]

#50 Y por eso por defecto estaba el planificador que tiene ahora y en versiones de escritorio se ponía el otro. No entiendo por qué esos parches no están en el mainline.

/cc #49

[#53 Desactivado]

#52 Porque simplemente usando un mejor planificador para E/S que para la CPU era suficiente en muchos casos.
http://algo.ing.unimo.it/people/paolo/disk_sched/

[#1 tul]

se sabe cuando (o si) llegaran a la rama oficial?

[#2 mr_b]

#1 No sé qué tal le habrá sentado el paper a Linus Torvalds…

[#4 tul]

#2 alguien ha confirmado la mejora del rendimiento con el parche este? si no he leido mal los ficheros llevan en github un mes y no habia escuchado nada hasta el momento. tu lo has probado?

[#6 tul]

#4 hombre a eso me referia, si habia pruebas realizadas por terceros no vinculados al paper.

[#7 mr_b]

#6 Pues no lo sé. Habrá que investigar más.

[#11 Desactivado]

#4 tengo el kernel 4.4 hace tiempo, ¿yo ya lo tengo?

[#26 PauMarí]

#11 ayer puse 4.5.1 de Arch y me dió la impresión que el KDE iba más fino pero no me preocupé en mirar las novedades, la vedad.

[#45 GoDie]

#19 Si que los utiliza, tiene que ver con un supuesto bug en el scheduler, que es el encargado de tratar los threads encolados y darles paso a los cores libres y otras cosas relativas a planificaciones de tareas, supuestamente en aplicaciones intensivas había un bug que provocaba un 13% de latencia en el que permanecían cores en estado idle durante y el scheduler no daba paso a esos threads encolados.


La mejora de rendimiento para el usuario común serán cercana a un inmenso 0 muy posiblemente
cc #4 #11 #26


Dicho bug no quiere decir que funcionara mejor que windows, por que habría que ver que tal van dichas aplicaciones intensivas en windows, y dado que normalmente se utiliza linux en aplicaciones científicas debido a su mejor rendimiento, podemos deducir que aun con el bug seguramente fuera mejor dichas herramientas que windows cc #8

[#54 fayser]

#19 no es que no los aprovechase, es que en ciertas circunstancias no conseguía hacer uso del 100% de la capacidad de todos los cores, dejando tareas paradas durante algunos milisegundos cuando podían ser ejecutadas por algún core que estaba sin hacer nada.

Como dice #45, no esperéis notarlo en el escritorio. Para llegar a esas circunstancias hace falta tener todos los cores al 100% y que además el planificador se quede "atascado", y con el parche hablan de mejoras de rendimiento en esos casos concretos de orden del 20%. En resumen, nada que vayas a notar.

[#59 GoDie]

#54 el readme del git habla de segundos! no ms.

Aunque me extraña un poco un bug de parones de segundos no descubierto e igual erraron ellos en el readme

[#65 GoDie]

#45 Definitivamente 0 por que el bug solo se da en supercomputadoras NUMA

cc #4 #26

[#66 PauMarí]

#65 mmmm no es mi fuerte la arquitectura de CPUs pero además del i5, que no lo és, tengo algunos xeon que ahora mismo ni puñetera idea de como los ve el sistema como npi de si solo afecta o máquinas multi procesadores pero lo que tengo claro es que notarse dudo que se notaría, solo era una respuesta subjetiva.

[#68 Desactivado]

#65 Hay equipos de trabajo incluso domésticos con arquitecturas NUMA, por ejemplo cualquier equipo con una placa biprocesadora

[#72 GoDie]

#68 Claro algo comun en computadoras personales.

que tengas un ordenador para computaciones de alto rendimiento en casa o sea domestico no quiere decir que sea un sistema de escritorio, solo que eres muy posiblemente gilipollas.

[#74 Desactivado]

#72 Primero el insulto te lo podías haber ahorrado, yo no te he insutado a ti, y segundo, que tu no lo uses no quiere decir que el resto de gente no lo use, no es algo raro un sistema biprocesador en ámbitos profesionales. Por ejemplo, cualquier Mac pro por decir un ordenador "conocido" lo puedes configurar con dos procesadores

[#75 GoDie]

#74 Yo no te he insultado si no sabes leer es tu problema.

(salvo que seas de los que tengas un ordenador de varios procesadores en casa para navegar por internet y cascarte peras con youporn, entonces si, aunque yo no lo llamaría insulto tampoco
si no un adjetivo para describirte)

Yo estaba hablando de ordenadores personales o de escritorio analfabeto (ahora si) que ganaría 0. No para cálculos o temas específicos de empresa.

Aprende a leer antes de entrar a comentar campeon.

[#76 Desactivado]

#75 la perra gorda para ti. Paso de tener debates con gente con la educacion en la punta del cipote, como es tu caso. ¿Sabes que es lo peor? Que mayormente llevas razon, es cierto que los sistemas NUMA no so demasiado habituales, pero tus asquerosas formas te pierden

[#78 GoDie]

#76 Tu comprensión lectora es el problema y el no saber reconocerlo.

No necesito ganar ninguna "perra gorda"

[#21 Desactivado]

#2 Me siento honrado de ser quien ponga esto en este hilo. Un clásico.

[#31 yusavi]

#21 Es realmente interesante cómo el gesto refleja realmente el sentimiento interno del muchacho. Yo cuando lo hago no consigo darle esa fuerza y vigor que transmite.

[#81 Pepitorl]

#79 El problema de los hosting es que si buscas algo barato (estilo ramnode, digitalocean o similares) para poner 4 mierdas, muchas veces son máquinas virtualizadas con openvz donde no puedes actualizar el kernel.

Tengo algunas máquinas de ese estilo:
Linux ------ 2.6.32-042stab102.9 #1 SMP Fri Dec 19 20:34:40 MSK 2014 x86_64 GNU/Linux

[#82 Desactivado]

#81 RamNode y DigitalOcean no son especialmente baratos en relación a lo que ofrecen. Para cosas pequeñas, y no tan pequeñas, últimamente me cae mejor Scaleway, que dan máquinas sin virtualizar por horas.

[#84 Pepitorl]

#82 14$ 1 año de una máquina, ya de por si es muy barato, eso si, poca ram, poco hdd, pero para una web o un team speak va que chuta, y la red funciona mil veces mejor que la de algunos servidores dedicados que tengo en OVH

[#85 Desactivado]

#84 ¿Cuál es la oferta de $14/año? Lo que más me suele echar atrás de contratar en USA son los límites de transferencia, que aunque 1TB pueda ser suficiente para muchas cosas, me sigue gustando más el "200Mbps unmetered", por si las moscas.

[#86 Pepitorl]

#85 Ostias, han subido muchísimo los precios en ramnode, igualmente, código de descuento: 10% OFF ANY NEW SSD VPS! Coupon: SSD10

http://www.ramnode.com/vps.php

Tienen servers en NL

[#87 Pepitorl]

#85 Se me olvidaba, tienen 1gbps y la verdad, va muy bien:
https://www.speedtest.net/result/5271005143.png

[#8 Desactivado]

Por una vez que windows lo hace mejor pero en windows 8 en adelante el win 7 los micros AMD FX de 8 nucleos no iban muy finos que digamos hasta un linux los usaba mejor.
Esto es los fabricantes de harware que quieren vender.

[#9 eli_baley]

#8 He tenido que releer tu comentario, y aún así creo que no lo entiendo.
Pon signos de puntuación, hombre...

[#10 Desactivado]

#9 Digo que el uso de los multi cores en windows hasta hace nada era peor incluso, solo windows 8 y 10 mejoraron ese aspecto.

[#22 cosmonauta]

#10 Hace ya unos años que existe windows8....

[#57 Desactivado]

#9 No eres lector multicore por lo que veo, que desaprovechao.

[#56 jbko]

#8 Oye, ¿dónde dice que Windows lo hace mejor? la comparación la hacen con respecto al kernel sin parchear.

[#42 Desactivado]

Bah. Esto con GNU/hurd no pasa

[#44 Desactivado]

#42 Cuidado con Hurd que puede ser el futuro. Hace 24 años decian lo mismo de Linux contra los Unix comerciales.

[#51 xosevp]

#44 Hurd es un zombi

[#71 rafael90]

#42 GNU/hurd no pasa (punto)

[#73 Desactivado]

#71 GuixSD va a integrar Hurd próximamente en su sistema. Considera GuixSD la distro FSF "de facto" de GNU/Linux, al integrar Guile y mucha de la filosofía de Stallman.

[#80 Desactivado]

#42 Tú ríete, pero cuando tengas 100 cores, ya veremos qué funciona mejor, si Linux o Hurd... o si acaban convirtiendo Linux (kernel monolítico) en Hurd (microkernel).

[#13 Desactivado]

Tampoco parece que este siendo un problema muy grave viendo las mejoras que consiguen.
Ahora bien, entiendo que esto llevará a un mejor soporte multicore en las distribuciones y que para los que tenemos equipos potentes no supondra un avance notable en el rendimiento.

Con ssd y 8gb de ram que puede ir mas rapido todo? Medio segundo? Ni me entero.

[#14 Desactivado]

#13 No es tanto la herramienta que tengas, sino el problema al que te enfrentas con esa herramienta.

[#16 briarreos]

#13 No te enteras hasta que has de hacer 100000 operaciones en las que cada una tarda "medio segundo más". Lo cual supone 14 horas más.

[#17 mangrar]

#13 Hombre con SSD mejora el rendimiento mucho mas que medio segundo, son varios segundos, comprobado por mi mismo cuando le puse una SSD a mi Mac Mini de 2009.

[#32 fusta]

#17 acabo de cambiar el chip de mi Mini de 2006 al ultimo que le puedo poner (Core 2 Duo T7200, 15€ en ebay!), y un SSD de 64Gb que me ha costado 30€, y parece que tengo máquina nueva, acabada de salir de la fábrica...

[#33 mangrar]

#32 si, es brutal lo de los SSD. La verdad es que ya me iba lento con El Capitan, pero con el SSD, vuela.

[#60 fusta]

#33 bueno el mío el pobre lo limitan al OS 10.7, pero vaya, puedo instalarle casi cualquier cosa. Pero vaya, va a estar conectado a la tele.. aguantará espero hasta que los contenido en UHD (y una nueva tele) sean el estándar

[#83 mangrar]

#60 Yo cuando me limiten el mío, le pondré una distro de linux.

[#69 ochoceros]

#32 Me extraña que no le puedas subir todavía más de procesador. Yo acabo de cambiar en mi portátil un T7200 por el T9500 y también tirado de precio. Y la diferencia en rendimiento se nota bastante, no ya por cache sino también por velocidad.

[#39 joffer]

#17 Pienso que no tiene nada que ver la mejora en acceso de dato a medio físico que el planificador de tareas.

[#46 mangrar]

#39 no, nada tiene que ver.

[#27 Desactivado]

#13 No es una cuestión de transferencia de datos, sino de cálculo. En aplicaciones que realizan cálculos intensivos puede suponer una diferencia enorme.

[#40 GoDie]

#13 poco tiene que ver el SSD o la ram

[#41 Desactivado]

#13 En el ordenador de tu casa no lo notas, en la NASA verás la pechá de reír cuando se enteren de que los cálculos para el lanzamiento de la sonda se retrasan una semana. O que los resultados de ese mega estudio conjunto sobre física de partículas se retrasan meses.

[#43 Desactivado]

#41 Pues supongo que el parche en cuestión conseguirá hacer que vuele el empleo de los cores, pero debe haber algún motivo por el que el top500 esté ya plagado de linux.

[#47 Desactivado]

#43 No he dicho en ningún momento que Linux no merezca estar ahí, mas bien he señalado el alcance que tiene en cosas muy grandes.

[#19 angelitoMagno]

No entiendo. ¿Linux no estaba aprovechando las ventajas de tener varios cores? Me resulta difícil de creer que en 10 años nadie hubiera corregido esto.

[#29 Desactivado]

#19 Antes ya se cargaron el "big SMP lock".

[#70 Desactivado]

#19 Si las usaba, pero siempre se puede mejorar. Por eso sale una versión nueva del kernel cada pocos meses

[#18 Desactivado]

Entre la terminología técnica y vuestra sintaxis no me he enterado de una puta mierda.

[#28 Desactivado]

#18 Resumiendo:

[#34 PauMarí]

#18 que según los papeles un coche tiene 6 cilindros y 220 CV pero resulta que sólo utiliza efectivamente 5 cilindros por tanto resulta que solo tiene, pongamos, 180 CV efectivos, más que suficientes para su uso normal.
Sobre la sintaxis no puedo ayudar, ya ves lo que hay.

[#36 Desactivado]

#18 que lan liao parda

[#15 Desactivado]

No lo creo, con lo potente que es Linux.

[#20 mangrar]

Propongo cambiar el título de la notícia para que llegue a destacada:

Planificador del kernel de Linux: una década de procesadores inutilizados que Podemos aprovechar [ENG]

[#58 lestat]

¿Todavía seguís usando el Kernel de Linux?
Yo cogí la primera versión y lo tunee, mejoré y recompilé y es el que uso desde hace años...

[#62 Desactivado]

Luego el hosting te limita a un Centos 6 con kernel 2.6...

[#64 Desactivado]

#62 kernel 2.6 con parches de la rama 3.x .

[#67 cosmonauta]

#62 Si el hosting te limita, cambia de hosting. Que para algo pagas.

[#79 Desactivado]

#62 Mi hosting me limita a... instalar lo que me salga de los cojones, que para eso tengo acceso al iDRAC. Si quiero hasta le puedo tunear la BIOS.

Como te dicen, si tu hosting te limita, cambia de hosting.

[#23 Desactivado]

Debe ser errónea, estamos hablando de Linux, el SO tan perfecto que solo pudo ser traído por los dioses.

[#30 parrita710]

#23 Linux no es un SO.