El Sun, 31 Jan 2010 13:59:50 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 10:40 -0000, Camaleón escribió:
Pues eso es lo que digo. Que sí pueden acceder a más de 4 GiB. Y ese remapeo es el que hace el PAE lento. Y a mayor cantidad de memoria ram física, peor >:-)
El último párrafo parece indicar que una aplicación sí puede acceder a más de 4 GiB. mediante la función mmap() :-?
Sí, indirectamente, y con perdida de eficacia.
A ver, que te lias un poco.
Un programa en 32 bits no puede acceder a más de cuatro gigas. Es decir, no puede decir, "dame la posición de memoria 4,5GiB" y quedarse tan ancho. Es que ni siquiera puede escribir la cifra 4,5GiB como número entero en el bus de direcciones.
Con un kernel de 32 bits sin PAE, no.
No obstante, puede emplear algunas funciones de librería que sí les permitirían acceder a trozos de memoria enormes, mapeandolas, y siendo conscientes de ello de alguna forma. Es decir, podría reservar un trozo de 6 GiB dividiendolo en trozos menores y accediendo a cada trozo por separado. Pero no podría emplear la operación del procesador de buscar un string en todo el trozo de 6 gigas, tendría que hacer varias búsquedas, y usar artimañas para buscar el string en las fronteras entre los trozos divididos.
Pues eso, que *sí* pueden.
O sea, que no. Si tienes programas que necesiten más de cuatro gigas, emplea procesadores y sistemas de 64.
Es que no sabes cuándo un programa (o una operación) te va a necesitar más de 4 GiB, bueno, 3 GiB.
Que es muy distinto de usar un sistema de 32 bits con 8 gigas, como tengo yo, porque esa memoria se emplea para caché principalmente, que por ineficaz que sea siempre será más eficaz que el disco.
Lo que no tiene sentido es tener un procesador de 64 bits, más de 8 GiB de ram y un kernel-pae, porque te penaliza.
Exacto, que es lo que precisamente estaba criticando Linus. Retomo del correo antiguo:
*** http://lwn.net/Articles/356724/ (...)
And for the kernel, the bigger virtual address space really is a _huge_ deal. HIGHMEM accesses really are very slow. You don't see that in user space, but I really have seen 25% performance differences between non-highmem builds and CONFIG_HIGHMEM4G enabled for things that try to put a lot of data in highmem (and the 64G one is even more expensive). And that was just with 2GB of RAM.
(inciso de Camaleón: nótese el "and the 64G one is even more expensive. And that was just with 2GB of RAM").
No le veo el sentido a codificar para 64 gigas cuando sólo tienes dos. Eso hay que probarlo en un sistema con 64 gigas de verdad.
Pues eso es lo que estaban discutiendo. Que el mero hecho de compilar el kernel con esa opción del HIGHMEM ralentiza las operaciones de memoria una barbaridad. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org