El Miércoles, 19 de Mayo de 2004 23:11, Cristian farias escribio:
> > Si me aburro a ver si hago un programita que haga infinitas copias de sí
> > mismo hasta que pete la memoria, a ver qué hace el sistema en ese caso.
> > No sería nada difícil. Ummmmmmmmm...
>
> Una ves me puse a jugar con eso y descubri algo super interesante.
>
> Hice un programa simple:
>
> while(1)
> fork();
>
> Lo que hacia era dejarme pegada la maquina (por razones obias)
Esas razones obvias son que tendrías miles y miles de procesos, y si el kernel
era de las series 2.4 o anteriores, el rendimiento se degrada con el aumento
de procesos, hasta el colapso.
La gracia en los nucleos 2.6 es que el scheduler, el planificador de procesos,
es en todos sus aspectos de complejidad O(1). Esto significa que su
rendimiento no empeora al aumentar el número de procesos, es decir, si para
trabajar con N procesos consume M recursos, para trabajar con 10*N procesos
consumirá, aproximadamente, 10*M recursos (o con alguna constante aplicada).
El diseñador del nuevo planificador, Ingo Molnar, dijo que para hacer pruebas
un día en su sistema (un ordenador normal, no un cluster ni nada de eso) hizo
un programa que creaba 100000 hilos y después los destruía todos. El programa
tardó 2 segundos en ejecutarse, y el sistema continuaba OK. :-)
El programa que yo tenía en mente era más acerca del consumo de memoria, de
forma que cada nuevo proceso reserve memoria con "malloc", pero no la libere,
y esperar hasta que pete el primer proceso.
> Cuando lo modifique a esto:
>
> while(1) {
> fork();
> sleep(1);
> }
>
> El cuento cambiaba radicalmente y el sistema me controlaba los procesos
> que se creaban, ademas el sistema se realentizaba pero no se caia,
> puediendo mantener un numero esatico de procesos.
>
> Curioso.
Sí, bueno, era de esperar, si esperas un segundo la cosa se ralentiza mucho,
pero si lo dejas suficiente tiempo (se podría calcular, creo que sigue un
crecimiento exponencial) también acabaría colapsando el sistema.
Haplo