EDICIóN GENERAL
277 meneos
2212 clics
El rendimiento del nuevo kernel compensa los parches de Meltdown

El rendimiento del nuevo kernel compensa los parches de Meltdown

Meltdown, Spectre y las diversas soluciones para mitigar esas peligrosas vulnerabilidades de hardware que permiten acceder a la memoria del sistema nos van a acompañar en el desarrollo del kernel durante un tiempo. Respecto a Meltdown, el desarrollador Greg Kroah-Hartman nos trae desde su cuenta de Google+ noticias positivas en relación al impacto en el rendimiento de los parches KPTI (Kernel Page-Table Isolation). Cita un reciente estudio en el que se afirma que Linux 4.15 es un 7-9 % más rápido que versiones previas.

| etiquetas: rendimiento , kernel , meltdown , compensa , greg kroah-hartman , kpti
122 155 4 K 286 linux
122 155 4 K 286 linux
Es más. Increiblemente en algunos AMD...después del parche el rendimento mejora.
#1 ¿en serio?
Esto me suena a la reparación de los diesel de Volkswagen, que misteriosamente no afectaba al rendimiento de los motores. Se queda uno con la sensación de que nos venden productos cojos, con un "colchón" de mejora aplicable en caso de que surja un problema, para poder evitarse demandas legales.
#2 Si, y lo veo correcto si ese margen de seguridad sirve para que haya menos desgaste y menos averías.
#3 Pero si cuando surge una incidencia, se "consume" el margen, empiezas a estar expuesto a ese desgaste y averías. Que no digan que las actualizaciones son inocuas.
#4 Linux es como el carburador de un biodiesel, y Windows es más como el pistón de un cuatro tiempos. Mucha gente cree que en determinadas situaciones pueden rendir mejor si se les fuerza pero, tal y como dijo el mismísimo Andrew S. Tanenbaum:

"esto es un mito, y en muchos casos el usuario pierde potencia de motor a largo plazo; cualquier experto en sistemas operativos sabrá que la única manera de darle una vida larga y duradera a nuestros vehículos consiste en no forzar nunca la maquinaria, especialmente si nos encontramos con una caja de cambios manual"
#5 Calla y sigue cargando cintas en la camioneta. :-P
#5 No sé si entiendo lo que quieres decir, pero que conste que los diesel no tienen carburador, Y que pistón y cuatro tiempos tienen tanto diesel como gasolina.

Vale, ya me retiro.
#5 pero de qué pollas está hablando este tio??
#29 perdón si he utilizado términos algo técnicos. Intentaré explicarlo para la gente de letras: el significado intrínseco de los kernels monolíticos no sólo reside en la semántica de la etimología de los términos; muchos historiadores y lingüistas coinciden en que los aspectos culturales de Linux Torvalds y de Finlandia en general tuvieron cierto peso a la hora de determinar qué función o qué procedimiento se utiliza a la hora de repartir tiempo de computación entre los procesos del sistema—sin olvidar los procesos de los usuarios y su trasfondo inherente—.
#34 De todos modos el algoritmo actual de multitasking en linux es bastante moderno.
#34 No sabes ni poner bien el nombre de Torvalds.
#56 perdón, corrijo: GNU/Linux Torvalds
#57 Perfecto!
#5 Oh Tanenbaum, oh Tanenbaum, wie grün sind deine Blätern!
#2 #3 Pero por otro lado esos mismos productos tienen su obsolescencia programada.
#2 En este caso hay un motivo razonable. Han estado cerca de un año trabajando en mejorar el rendimiento del kernel. Han conseguido incrementar su velocidad en alrededor de un 9%. Ahora con la pérdida por el parche, el rendimiento es +9 - 11 = -2%. O sea, que gracias a que el kernel ahora es mucho mejor, la pérdida por el parche no es muy notable.
#24 Si usas AMD habrás ganado un 20% de rendimiento frente a equipos Intel en SO Linux. Ese es el titular que yo pondría.
#37 Tienes razón, es un dato importante a tener en cuenta sobre todo ahora que si quieres AMD tienes que buscarlo específicamente porque lo usual es Intel.
Venía a preguntar si el 4.15 entrará en los backports de Stretch, pero aquí no hay más que puterío (con perdón)
#7 4.14 si que está en stretch-backports pero de 4.15 solo hay una rc8 en experimental. No hace ni una semana que ha salido 4.15, dale tiempo y saldrá para stretch-backports :hug:
#7 Si es para tu pc personal, yo no me preocuparía por ponertelo de backports. Actualizarán el kernel que ya llevas con los parches y perderás 1-2%. Es decir, alguien que ni se haya enterado estará seguro y no notará nada. Supongo que llevas la estable porque todo funciona y no tienes que preocuparte de nada.
#7 mariconadas. Compílalo. :-D
#42 Sólo con compilarlo en modo nativo para que utilice las instrucciones específicas de tu procesador supone una mejora importante:

echo $CFLAGS
-O3 -march=native -mtune=native -pipe

wiki.gentoo.org/wiki/GCC_optimization/es#.C2.BFQu.C3.A9_son_CFLAGS_y_C
(Uso -O3 porque Intel compila así sus paquetes en la distro ClearLinux, que es la que más rendimiento da ahora mismo, y aparte es la única forma de que se compile usando instrucciones AVX)

Yo compilo el kernel usando este…   » ver todo el comentario
#49 Si imagino por unos segundos los log que me podría tirar intentando compilarlo, te aseguro que se me quitan las ganas. No pertenezco al grupo de quienes hacéis avanzar la comunidad, me faltan conocimientos y a día de hoy, capacidad cognitiva para adquirirlos. Te agradezco tanto el comentario sobre la compilación, como que pongas tus diseños al servicio público. Eres, sois, de lo mejor.
#49 muy interesante el script. Me lo he empollado. Lo del "fancontrol" no lo conocía. :-)
#53 No es un paquete que venga instalado por defecto, pero si lo configuras te permite hacer un control manual de los ventiladores en base a la temperatura de algún sensor. Es el equivalente a speedfan en Windows, aunque sin interfaz gráfica.
Gatopardismo informático.
Mmmmm, un nuevo kernel que supone una mejora de rendimiento de un 9% pese a kernel, ¿Y lo implementan así, de golpe?.
Eso supondría, excepción hecha de Meltdown, una mejora de entorno a un 30-40% de rendimiento en el peor de los casos y según datos previos.

Si es cierto, una de dos, o los desarrolladores estaban frenando conscientemente la evolución del kernel o Meltdown no supone un problema tan serio como se decía.
#10 estan haciendo la mitica,yo te digo que he consegido que todo funcione de 10,luego en verdad es un 5,en el mejor de los casos...
#13. Eso ocurre en los casos donde los intereses comerciales están muy por encima de la ética profesional, lo cual no es el caso ni la filosofía en el Software Libre ni en Gnu/Linux.

#16. No estoy de acuerdo. En cualquier caso la comunidad de usuarios no tardará en confirmar los que los desarrolladores del kernel comparten en los foros.
#15 eso pasa en el dia a dia de cualquier trabajador de informatica,cuando tienes un vendehumos en el equipo....

Mira el rendimiento de Ryzen,que siendo espectacular,no era tan bueno como prometieron los benchmark...
#15 estoy de acuerdo en lo ultimo al 100%,la proxima vez no edites que no notifica que has respondido otra vez
#26. Tengo que editar casi siempre o por temas ortográficos o por añadir o corregir algo importante. No hay otra intención.
Y lava más blanco.
Maldito linux,maycrosoft te aplastara!!!
AL finál habra que darle las gracias a Intel... creo que es engañoso el tema es cómo de rápido sería el kernel nuevo potimizado sin el parche.. por que igual ganariamos mucho mas de 7%
#14 siempre puedes recompilarte un kernel con el flag de desactivar los parches y sacar/comparar estadisticas.

Pero vamos, que a menos que te interese evaluar el impacto en un servidor, tampoco me veo mucha utilidad a ver cuanto se ha perdido de eficiencia. La realidad es que lo más probable es que vas a preferir tener el kernel parcheado por el riesgo que supone :-P
bueno, iría más rápido de no existir esos errores.
¿nadie dice nada de que lo han comunicado por Google+ ?
#19 que es eso de Google + ?
#19 que problema hay? La comunidad libre se comunica mucho por g+
#22 "la comunidad libre" xD
#30 sí, es literal pero también iba con coña por eso jeje
#22 Pues que daba por hecho que Google lo dejó morir, es más, pensaba que ya habían cerrado y no permitían nuevo contenido.
#51 eso es google code.
Sugerencia de etiqueta: las gallinas que entran por las gallinas que salen.
Los intel que se están vendiendo ahora, sabiendo que ya vienen con ese problema, deberían bajar de precio. Se que es más un sueño húmedo, pero estás comprando algo que viene con defectos.
Y con ahora, incluyo las 2 o 3 generaciones anteriores.
El problema es que para entornos profesionales (servidores) no se pueden hacer saltos de kernel tan rápidamente. Debéis pensar que muchos entornos aún se mueven en 2.6
#32 Totalmente de acuerdo. Yo todo entorno profesional que he visto "que se precie" se basa en RHEL y así están las cosas:
access.redhat.com/articles/3078
Aún queda un trecho, aunque si lo que se clama aquí es cierto imagino que se darán más prisa para actualizar.
#32 Si, 2.6 donde no tengo un 2.4.16. 8-D

Y soy feliz con ello vendiéndole al cliente un uptime de más de 4000 días.
#32 2.6.32 Uso yo. Y aun va de lujo.
El titular dice lo contrario que el artículo, ¿con qué nos quedamos, va más rápido o más lento?
#36 En términos futbolisticos: Al palo en el minuto 93 y quedaron 1-1.

Podria haber sido la version mejor optimizada de la historia y nos hemos quedado incluso un poquito peor en rendimiento. Ojalá nuevas optimizaciones nos consigan otro 8-9% extra.
La gente ya se está animando a instalar los parches de Meltdown/Spectre, sí, en producción. Los resultados son no tan malos como se temía, incluso en servidores de base de datos.
Este es el año de Meltdown en el escritorio.
El que peca y reza empata!!! parches lentos, kernel mas rápido ya tenemos un ganador: Winux!!!
confirmo que debian 9 con parche kaiser es mas lento que la debian 8 sin parche kaiser

y ahora que coño hago ?

menéame