Re: [Programación] alloc grande sin swap

[Angel Arancibia]

El día 20 de junio de 2008 16:06, Leonardo Rios <rios.lj en gmail.com> escribió:
> 2008/6/19 Rafael Bidegain <r.bidegain en gmail.com>:
>> Hola a todos.
>>
>> Anoche entre cervezas y nachos, en una meet de rubyes, alquien comentó
>> [0] que es posible ocupar gran cantidad de memoria y lockearla para
>> evitar swap y lograr rapidez en el proceso.
>>
>> como se implementa eso?
>>
>> //se me ocurre algo así:
>> char *p;
>> p = (char *) malloc(1024*1024*100);
>>
>> //Desde Ahora deberia el SO _NO_ debería mandar el contenido de p a swap.
>> lock(p);
>>
>> //despues debería llamar a unlock y a free
>>
>>
>> notas:
>> [0] no especificó lenguaje, estimo que se refería a C.
>> yo no había tomado mucho, la otra persona tampoco  :)
>>
>> gracias
>> --
>> /* Rafael Bidegain
>> Linux Registered User # 204304
>> CaFeLUG Grupo de Usuarios de Software Libre de Capital Federal
>> http://www.cafelug.org.ar */
>>
>
> Yo he utlizado lock para lock(ear) creacion de procesos o hilos con
> pthread_create.  De esta manera te aseguras que otro proceso o hilos
> cuando es creado no utilize esa porcion de codigo hasta que se
> deslock(ee).
>
> Al margen de esto no le veo mucha utilidad utilizar entre medio de esa
> porcion un malloc, pero puede ser que si.  Lo que esta bueno de no
> usar swap es memoria compartida, capaz que se refiere eso el huachi.
>

No creo que se estén refiriendo a lo mismo. Leonardo se esta
refiriendo al problema de región critica (ojo que no es lo mismo
threads-hilos que procesos, pero da casi igual aca).
Lo que dice Rafael es lockear un cacho de ram para que nunca sea
suspendida (swapeada). Esto, si es que existe, debería ser una
funcionalidad del SO (kernel) a travz de una llamada a sistema, ya que
para hacer eso, se deberia lockear o marcarla de alguna forma (que es
lo que hacen los locks en definitiva ... ) dentro del kernel, ya que
es este quien la administra. Además, debería tener que tener permisos
de root (el proceso.. en realidad la llamada) ya que sino ...


Saludos
Angel