Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 17:06, Juan Antonio escribió:
> El 06/05/11 16:57, Camaleón escribió:
>> El Fri, 06 May 2011 16:33:04 +0200, Juan Antonio escribió:
>>
>>> El 06/05/11 16:18, Camaleón escribió:
>>>>> mmm ¿Estas seguro de lo de la memoria "por proceso"? Las direcciones
>>>>> virtuales siguen siendo de 32 bits ¿No? Es decir, aunque puedas usar
>>>>> tres niveles de tablas de páginas el espacio de direcciones de un
>>>>> proceso sigue siendo de 2^32 bits
>>>> Sí, las direcciones son de 32 bits pero los procesos pueden acceder a
>>>> más memoria mediante la paginación, de la misma forma que se mapea la
>>>> ram "inaccesible" con el PAE.
>>>>
>>>> En windows lo consiguen mediante el AWE (p. ej., para que un sistema de
>>>> 32 bits con PAE habilitado pueda dedicar a una aplicación de base de
>>>> datos más de 4 GiB de ram) y en linux se puede obtener el mismo
>>>> resultado con mmap... o eso pone en la wikipedia:
>>>>
>>>> http://en.wikipedia.org/wiki/Physical_Address_Extension
>>>>
>>>> "(...) For application software which needs access to more than 4 GB of
>>>> RAM, operating systems may provide some special mechanisms in addition
>>>> to the regular PAE support. On Windows this mechanism is called Address
>>>> Windowing Extensions, while on Unix-like systems a variety of
>>>> techniques are used, such as using mmap() to map regions of a file into
>>>> and out of the address space as needed."
>>>>
>>>> Eso sí, las aplicaciones tienen que estar preparadas (programadas) para
>>>> poder hacerlo.
>>>>
>>> precisamente la paginación es lo que permite que el sistema pueda
>>> acceder a mas memoria física, la mmu divide los campos de una dirección
>>> de memoria virtual en diferentes niveles de páginas, esto permite
>>> direccionar mas memoria de la que hay disponible ademas de aislar los
>>> espacios de direcciones entre los procesos, pero otra cosa es que el
>>> proceso en sí usa direcciones de 32 bits, es decir, en última instancia
>>> el proceso no ve mas de 2^32 bits de direcciones virtuales,
>> Sí, el proceso sólo puede acceder directamente a esos 4 GiB (un poco
>> menos me parece, unos 3 y pico) pero a efectos prácticos es indiferente,
>> si ese proceso necesita más memoria no se te va a quedar colgado, la va a
>> paginar (siempre y cuando la aplicación lo permita, ojo, que no todas
>> están preparadas para eso).
>>
>>> juraría que esto es asi incluso con los sistemas de 64 bits pero de
>>> esto no estoy seguro.
>> En los sistemas operativos de 64 bits no es necesario el PAE.
>>
>>> Diferente es que despues esa memoria que ve el proceso pueda
>>> estar físicamente en direcciones mas allá?? de los 4 G
>>>
>>> http://kerneltrap.org/node/2450
>>> This is enabled via the PAE (Physical Address Extension) extension of
>>> the PentiumPro processors. PAE addresses the 4 GB physical memory
>>> limitation and is seen as Intel's answer to AMD 64-bit and AMD x86-64.
>>> PAE allows processors to access physical memory up to 64 GB (36 bits of
>>> address bus). However, since the virtual address space is just 32 bits
>>> wide, each process can't grow beyond 4 GB.
>>>
>>>
>>> Es decir, según lo entiendo yo, un proceso en cualquier caso ve un
>>> espacio de direcciones de 4G incluso aunque el sistema tenga 500 megas,
>>> y PAE te permite direccionar hasta 64G de memoria física.
>> Sí, pero repito, da lo mismo. Si tienes 16 GiB de ram física junto con un
>> sistema operativo de 32 bits con PAE, las extensiones pertinentes
>> habilitadas y la aplicación te permite acceder a más de esos 4 GiB, lo
>> hará, aunque obviamente el rendimiento no será el mismo (la paginación
>> penaliza el rendimiento) pero podrás destinar más de 4 GiB para servidor
>> de base de datos.
>>
>> Saludos,
>>
> Hola,
>
>
> sin parchear si no recuerdo mal era 3/1 3 para usuario y 1 para kernel.
>
> me refería a que incluso con una arquitectura de 64 bits el espacio de
> direcciones de un proceso sigue siendo de 4G a pesar de que físicamente
> se pueda hacer uso de toda la memoria disponible.
>
> Según el enlace de la lista del kernel puedes hacer una maña con mmap
> para mapear ficheros de mas de 4 gigas, pero por ejemplo no podrías
> tener mas de 4 gigas en memoria no mapeada, instrucciones + stack +
> memoria dinámica, en definitiva que no podrías hacer un malloc de mas de
> 4 gigas, supongo que ni de mucho menos pero es para hacerme entender.
>
> Un saludo.
>
>
Hola,
pero ni de coña, de un /proc/pid/maps en un sistema de 64 bits hay
direcciones de 64 bits, podría haberlo mirado antes y ahorrarme hacer el
ridículo.
Un saludo.
Reply to: