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
