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. -- To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4dc411e8.90...@limbo.ari.es