Tecnología, Internet y juegos
255 meneos
3626 clics

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” (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.

| etiquetas: planificador , scheduler , linux kernel , kernel , procesador desaprovechado
116 139 4 K 382
116 139 4 K 382
  1. se sabe cuando (o si) llegaran a la rama oficial?
  2. #1 No sé qué tal le habrá sentado el paper a Linus Torvalds… :troll:
  3. Cores, que no procesadores. Puede inducir a error.
  4. #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?
  5. #4 En teoría es el propio paper el que lo “demuestra”. Claro que ahora faltaría la revisión por pares.
  6. #4 hombre a eso me referia, si habia pruebas realizadas por terceros no vinculados al paper.
  7. #6 Pues no lo sé. Habrá que investigar más.
  8. 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. #8 He tenido que releer tu comentario, y aún así creo que no lo entiendo.
    Pon signos de puntuación, hombre...
  10. #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.
  11. #4 tengo el kernel 4.4 hace tiempo, ¿yo ya lo tengo?
  12. 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
  13. 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. #13 No es tanto la herramienta que tengas, sino el problema al que te enfrentas con esa herramienta.
  15. No lo creo, con lo potente que es Linux.
  16. #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. #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.
  18. Entre la terminología técnica y vuestra sintaxis no me he enterado de una puta mierda.
  19. 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.
  20. 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] :troll:
  21. #2 Me siento honrado de ser quien ponga esto en este hilo. Un clásico.  media
  22. #10 Hace ya unos años que existe windows8....
  23. Debe ser errónea, estamos hablando de Linux, el SO tan perfecto que solo pudo ser traído por los dioses.
  24. 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.
  25. #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 ;)
  26. #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.
  27. #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.
  28. #18 Resumiendo:

     media
  29. #19 Antes ya se cargaron el "big SMP lock".
  30. #23 Linux no es un SO.
  31. #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.
  32. #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. #32 si, es brutal lo de los SSD. La verdad es que ya me iba lento con El Capitan, pero con el SSD, vuela.
  34. #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.
  35. #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? xD
  36. #35 Ahora a esperar que Linus dé el visto bueno para integrarlo en el kernel. Mi Mint está esperando un nuevo parche. :-)
  37. #12 ¿alguien puede enlazar los insultos de linus al respecto ? :troll:
  38. #17 Pienso que no tiene nada que ver la mejora en acceso de dato a medio físico que el planificador de tareas.
  39. #13 poco tiene que ver el SSD o la ram :palm:
  40. #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.
  41. Bah. Esto con GNU/hurd no pasa :troll:
  42. #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.
  43. #42 Cuidado con Hurd que puede ser el futuro. Hace 24 años decian lo mismo de Linux contra los Unix comerciales.
  44. #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 xD cc #8
  45. #39 no, nada tiene que ver.
  46. #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.
  47. #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 :troll:
  48. Con Kolivas, propuso unos cambios en el planificador que mejoraban mucho su rendimiento. La respuesta del acomplejado de Linus, fue echarlo del proyecto.
  49. #49 Iba bien en multimedia, no en servidor.
  50. #44 Hurd es un zombi
  51. #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
  52. #52 Porque simplemente usando un mejor planificador para E/S que para la CPU era suficiente en muchos casos.
    algo.ing.unimo.it/people/paolo/disk_sched/
  53. #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.
  54. #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.
  55. #8 Oye, ¿dónde dice que Windows lo hace mejor? la comparación la hacen con respecto al kernel sin parchear.
  56. #9 No eres lector multicore por lo que veo, que desaprovechao.
  57. ¿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... xD

    </fantasma nivel 1990 como mínimo>
  58. #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
  59. #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 :shit:
  60. #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.
  61. Luego el hosting te limita a un Centos 6 con kernel 2.6...
  62. #62 kernel 2.6 con parches de la rama 3.x .
  63. #45 Definitivamente 0 por que el bug solo se da en supercomputadoras NUMA

    cc #4 #26
  64. #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.
  65. #62 Si el hosting te limita, cambia de hosting. Que para algo pagas.
  66. #65 Hay equipos de trabajo incluso domésticos con arquitecturas NUMA, por ejemplo cualquier equipo con una placa biprocesadora
  67. #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.
  68. #19 Si las usaba, pero siempre se puede mejorar. Por eso sale una versión nueva del kernel cada pocos meses
  69. #42 GNU/hurd no pasa (punto)
  70. #68 Claro algo comun en computadoras personales. ?( :palm:

    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.
  71. #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.
  72. #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
  73. #74 Yo no te he insultado xD 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. :palm:

    Aprende a leer antes de entrar a comentar campeon.
  74. #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
  75. #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.
  76. #76 Tu comprensión lectora es el problema y el no saber reconocerlo.

    No necesito ganar ninguna "perra gorda"
  77. #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
  78. #60 Yo cuando me limiten el mío, le pondré una distro de linux.
  79. #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
  80. #85 Ostias, han subido muchísimo los precios en ramnode, igualmente, código de descuento: 10% OFF ANY NEW SSD VPS! Coupon: SSD10

    www.ramnode.com/vps.php

    Tienen servers en NL
  81. #85 Se me olvidaba, tienen 1gbps y la verdad, va muy bien:
    www.speedtest.net/result/5271005143.png
comentarios cerrados

menéame