|
|
|
Secciones
Obrar mucho, y hablar poco; que lo demás es de loco.
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Barrapunto © 1999-2007. Contenido disponible bajo licencia Creative Commons Reconocimiento 2.5
Aviso legal
Re:¿Maravilloso?
(Puntos:5, Interesante)( http://www.terra.es/personal/diegocg )
Para ordenadores SMP (sobre todo los que tienen decenas de procesadores); la VM de freebsd es claramente inferior (nisiquiera arranca en ciertos sistemas).
Yo tambien tengo un dual (p3 2x800), y haciendo un en un freebsd 5.1 bajo carga pesada del disco se puede ver perfectamente como los procesos entran en el bloqueo "Giant". Si, es un FreeBSD 5.X. En Linux los usos del "big kernel lock" estan totalmente erradicados. Freebsd aun tiene que reescribir su vm para adaptarse a SMPs.
Por cierto, usar swap no tiene nada de malo. El swap son trozos de programas que no se utilizan. El que no se usara swap si que seria un verdadero bug.
Re:¿Maravilloso?
(Puntos:2)( http://www.terra.es/personal/diegocg )
Lo peor puede ser una fuga en el kernel. Esas no se puede recuperar; recientemente en el 2.6 habia una pero *creo* que se solucionó.
Tambien cuenta mucho el proposito que tengan los valores por defecto en ambos sistemas operativos. En linux 2.6, en casos como el que han mencionado antes; se recomienda jugar con /proc/sys/vm/swapiness y reportar que valor ha sido el mejor para tu carga particular.
Re:¿Maravilloso?
(Puntos:2)( http://mi.barrapunto.com/dardhal )
¿ no será algún programa/demonio que tenga en algun punto una fuga de memoria y que vaya cogienda sin parar hasta que llegue un punto en que el kernel diga basta y lo mate?
Hasta donde yo sé, si la memoria no me falla, si no entendí mal, etc... en 2.6.x se sabe que hay algún tipo de "leak" de memoria, que (creo) consiste en la no liberación de ciertos "slabs" (cat /proc/slabinfo) que se van acumulando a lo largo del tiempo.
Parece que las "cabezas pensantes" del asunto (Torvalds y Morton entre otros) saben y conocen el problema, y supongo que estarán investigándolo.En cuanto a lo de "matar el proceso cuando se pasa de la raya" es lo que se llama el "OOM killer" (Out Of Memory Killer) y es tema de arduos debates, no sólo en 2.6.x, sino también en 2.4.x, donde dicha funcionalidad aparece y desaparece cual río Guadiana.
En 2.6.0-test8-mm2 está el código del "OOM killer", y se llama a él desde "try_to_free_pages()" cuando el intento no es exitoso. Lo que pasa es que a pesar de la aparente sencillez del algoritmo "badness()" para averiguar el PID del proceso más culpable de la falta de memoria dicho algoritmo no siempre funciona a la primera (ni a la segunda, ni a la tercera, ni...) e incluso la función "int_sqrt" usada en el cálculo a veces devuelve cero, y como su resultado aparece en el denominador de una fracción...pues a veces en pleno "trashing" salen mensajes de interesantes divisiones por cero.
Si hay alguien que tenga ideas brillantes e implementaciones que funcionen bien para el concepto de "OOM killer", la fama, la fortuna y el reconocimiento general le esperan en "linux-kernel EN vger . kernel . org".