Re: Cambios en el kernel... ¿no más 686?
Hola, 2011/5/3 Camaleón noela...@gmail.com El Tue, 03 May 2011 13:34:24 +0200, Marc Olive escribió: On Tuesday 03 May 2011 12:48:58 Camaleón wrote: ¿Consecuencias? Pues que algunas personas tendrán que usar un kernel 486 en lugar del 686 ya que algunos modelos de micros no admiten PAE. Vale, pero eso no es ningun problema: He (Ben) also points out that these processors not supported by the 686- bigmem flavour seem to gain performance with the 486 flavour. El problema no es más que que cambiar de kernel. Pero te has parado en lo más interesante :-) (...) There is a small cost (up to about 0.1% of RAM) in the use of larger hardware page tables. En cuanto al rendimiento, pues tengo mis dudas (imagina un Core i7 con un kernel optimizado para un 486 que sólo puede ejecutar un hilo... no suena muy bien :-P). Recuerda que si el micro lo soporta, la elección de activar el PAE o no recae en el usuario. Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Sí, es cierto, no hay muchos, pero se olvida de las VM. Quizás puedas preguntar en el hilo en el que decidieron seguir hacia adelante con el cambio: http://lists.debian.org/debian-kernel/2011/02/msg00244.html Parece que nadie se opuso, aunque sí que se reconoció que algunas máquinas antiguas dejarían de poder llevar Debian Un saludo
Re: Cambios en el kernel... ¿no más 686?
On Tuesday 03 May 2011 15:23:05 Camaleón wrote: El Tue, 03 May 2011 13:34:24 +0200, Marc Olive escribió: On Tuesday 03 May 2011 12:48:58 Camaleón wrote: Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Sí, es cierto, no hay muchos, pero se olvida de las VM. Las VMWare y los servidores virtuales OpenVZ soportan la extension PAE, así que yo no tengo problemas. Desconozco si está soportado por QEMU, KVM y otras, o si alguien está especialmente interesado en emular micros con multithreading sin la extensión PAE. Saludos, -- Marc Olivé Blau Advisors www.blauadvisors.com -- 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/201105061222.08628.marc.ol...@blauadvisors.com
Re: Cambios en el kernel... ¿no más 686?
El Fri, 06 May 2011 11:32:35 +0200, Javier Barroso escribió: 2011/5/3 Camaleón El Tue, 03 May 2011 13:34:24 +0200, Marc Olive escribió: Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Sí, es cierto, no hay muchos, pero se olvida de las VM. Quizás puedas preguntar en el hilo en el que decidieron seguir hacia adelante con el cambio: http://lists.debian.org/debian-kernel/2011/02/msg00244.html Parece que nadie se opuso, aunque sí que se reconoció que algunas máquinas antiguas dejarían de poder llevar Debian Seguramente nadie se opuso porque desconocían el asunto :-) Yo me he enterado -3 meses más tarde- porque estoy suscrita a Debian News que si no se me pasa igualmente por alto (tampoco he leído ningún comentario sobre esto en la lista general). La VM donde tengo wheezy (una testing perpetua) no tiene habilitado el PAE/NX por lo que tendré que pensar qué camino seguir, si instalar el kernel pae o el 486 ya que ahora lleva el 686... aunque creo que al final tiraré por el 486. Saludos, -- Camaleón -- 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/pan.2011.05.06.10.32...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
El Fri, 06 May 2011 12:22:08 +0200, Marc Olive escribió: On Tuesday 03 May 2011 15:23:05 Camaleón wrote: El Tue, 03 May 2011 13:34:24 +0200, Marc Olive escribió: On Tuesday 03 May 2011 12:48:58 Camaleón wrote: Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Sí, es cierto, no hay muchos, pero se olvida de las VM. Las VMWare y los servidores virtuales OpenVZ soportan la extension PAE, así que yo no tengo problemas. Desconozco si está soportado por QEMU, KVM y otras, o si alguien está especialmente interesado en emular micros con multithreading sin la extensión PAE. Las VM lo admiten, pero repito, activarlo o no es opcional (yo no lo tengo activado en VirtualBox porque en ese equipo no me interesa un kernel pae). Saludos, -- Camaleón -- 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/pan.2011.05.06.11.03...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
- Original Message - From: Camaleón noela...@gmail.com To: debian-user-spanish@lists.debian.org Sent: Friday, May 06, 2011 7:03 AM Subject: Re: Cambios en el kernel... ¿no más 686? El Fri, 06 May 2011 12:22:08 +0200, Marc Olive escribió: Las VM lo admiten, pero repito, activarlo o no es opcional (yo no lo tengo activado en VirtualBox porque en ese equipo no me interesa un kernel pae). Saludos, -- Camaleón -- Déjenme hacerle una pregunta de novato. Que ventajas trae la tecnología PAE respecto a la i386? La verdad así por así no le veo sentido que no hagan los 2 tipos de kernel. Saludos Cordiales = || ISMAEL || = -- 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/AB32196C81164679BDB9ED82C1F60DAC@virpc05
Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 14:30, Ismael L. Donis García escribió: - Original Message - From: Camaleón noela...@gmail.com To: debian-user-spanish@lists.debian.org Sent: Friday, May 06, 2011 7:03 AM Subject: Re: Cambios en el kernel... ¿no más 686? El Fri, 06 May 2011 12:22:08 +0200, Marc Olive escribió: Las VM lo admiten, pero repito, activarlo o no es opcional (yo no lo tengo activado en VirtualBox porque en ese equipo no me interesa un kernel pae). Saludos, Hola, con arquitecturas de 32 bits direccionas 2^32 bits de memoria, esto son 4 G. Con PAE tienes 4 bits adicionales asi que direccionas 2^36 que si no me equipoco da un total de 64 G 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/4dc3f13c.1070...@limbo.ari.es
Re: Cambios en el kernel... ¿no más 686?
El Fri, 06 May 2011 08:30:22 -0400, Ismael L. Donis García escribió: (Ismael, si respondes debajo de una marca de firma (-- ) los que te respondan y los que te lean van a tener problemas) Las VM lo admiten, pero repito, activarlo o no es opcional (yo no lo tengo activado en VirtualBox porque en ese equipo no me interesa un kernel pae). Déjenme hacerle una pregunta de novato. Que ventajas trae la tecnología PAE respecto a la i386? La verdad así por así no le veo sentido que no hagan los 2 tipos de kernel. Además de lo que te ha comentado Juan Antonio (a lo que añadiría que también permite el uso de 4 GiB de ram por proceso siempre y cuando la aplicación esté preparada para ello), un kernel con el PAE activado permite utilizar el NX bit (no execute bit¹) que viene a ser una medida de seguridad para evitar la ejecución de código en un área determinada de la memoria. ¹http://en.wikipedia.org/wiki/NX_bit Saludos, -- Camaleón -- 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/pan.2011.05.06.13.41...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 15:41, Camaleón escribió: El Fri, 06 May 2011 08:30:22 -0400, Ismael L. Donis García escribió: (Ismael, si respondes debajo de una marca de firma (-- ) los que te respondan y los que te lean van a tener problemas) Las VM lo admiten, pero repito, activarlo o no es opcional (yo no lo tengo activado en VirtualBox porque en ese equipo no me interesa un kernel pae). Déjenme hacerle una pregunta de novato. Que ventajas trae la tecnología PAE respecto a la i386? La verdad así por así no le veo sentido que no hagan los 2 tipos de kernel. Además de lo que te ha comentado Juan Antonio (a lo que añadiría que también permite el uso de 4 GiB de ram por proceso siempre y cuando la aplicación esté preparada para ello), un kernel con el PAE activado permite utilizar el NX bit (no execute bit¹) que viene a ser una medida de seguridad para evitar la ejecución de código en un área determinada de la memoria. ¹http://en.wikipedia.org/wiki/NX_bit Saludos, Hola, 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 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/4dc40116.4050...@limbo.ari.es
Re: Cambios en el kernel... ¿no más 686?
El Fri, 06 May 2011 16:09:26 +0200, Juan Antonio escribió: El 06/05/11 15:41, Camaleón escribió: Además de lo que te ha comentado Juan Antonio (a lo que añadiría que también permite el uso de 4 GiB de ram por proceso siempre y cuando la aplicación esté preparada para ello), un kernel con el PAE activado permite utilizar el NX bit (no execute bit¹) que viene a ser una medida de seguridad para evitar la ejecución de código en un área determinada de la memoria. 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. Saludos, -- Camaleón -- 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/pan.2011.05.06.14.18...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 16:18, Camaleón escribió: El Fri, 06 May 2011 16:09:26 +0200, Juan Antonio escribió: El 06/05/11 15:41, Camaleón escribió: Además de lo que te ha comentado Juan Antonio (a lo que añadiría que también permite el uso de 4 GiB de ram por proceso siempre y cuando la aplicación esté preparada para ello), un kernel con el PAE activado permite utilizar el NX bit (no execute bit¹) que viene a ser una medida de seguridad para evitar la ejecución de código en un área determinada de la memoria. 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. Saludos, Hola, 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, juraría que esto es asi incluso con los sistemas de 64 bits pero de esto no estoy seguro. 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. 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/4dc406a0.90...@limbo.ari.es
Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 16:33, Juan Antonio escribió: El 06/05/11 16:18, Camaleón escribió: El Fri, 06 May 2011 16:09:26 +0200, Juan Antonio escribió: El 06/05/11 15:41, Camaleón escribió: Además de lo que te ha comentado Juan Antonio (a lo que añadiría que también permite el uso de 4 GiB de ram por proceso siempre y cuando la aplicación esté preparada para ello), un kernel con el PAE activado permite utilizar el NX bit (no execute bit¹) que viene a ser una medida de seguridad para evitar la ejecución de código en un área determinada de la memoria. 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. Saludos, Hola, 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, juraría que esto es asi incluso con los sistemas de 64 bits pero de esto no estoy seguro. 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. Un saludo. mm, supongo que esto lo aclara todo http://lkml.indiana.edu/hypermail/linux/kernel/0505.2/0082.html la clave estaba en such as using mmap() to map regions of a file into and out of the address space as needed. 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/4dc40a7c.4060...@limbo.ari.es
Re: Cambios en el kernel... ¿no más 686?
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, -- Camaleón -- 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/pan.2011.05.06.14.57...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
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. -- 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/4dc40e6d.5090...@limbo.ari.es
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. -- 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
Re: Cambios en el kernel... ¿no más 686?
El Fri, 06 May 2011 17:06:21 +0200, Juan Antonio escribió: El 06/05/11 16:57, Camaleón escribió: 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. 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. ¿Estás seguro de eso? :-? 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. Sí, sería como poner un parche para poder acceder a más memoria (igual que el PAE es una especie de parche para poder direccionar más cantidad de ram) pero posible, lo es :-) Saludos, -- Camaleón -- 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/pan.2011.05.06.15.33...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Juan Antonio escribió: 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. Buenas A mi me ha parecido interesante/instructivo, aunque no valga na, te doy un +5 XD Un saludo y buen finde Un saludo. - -- Si los tontos volaran, el cielo se oscurecería No me envié correos en formatos propietarios http://www.gnu.org/philosophy/no-word-attachments.es.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNxBRhAAoJEOWNzQnqy+fzxckH/iFNmt5VJRcWlMPRJd+yCYQS M2vyytYmjdr28YdsmkdFBuPz8j6j1c+oVwWF1hlfyrGz6AMU13aBkOzUiMpdJxdC kOqjDwS+aZNZBf4wsXaAQqooKN9bOg/tFHhsSS2adjtHUx8EH8ZFimhkjTvz0zHQ SNOpVN35R9DHCWfcoSng/e2qIo97sFqAkVhX+92HeQjtXfS9b/yZmrNr+IqvWceO q34exf+qV2N29yLwsxULwT9GfuQUYLnoLoGu7zpG1VaKr1q3CQCaTpiihTKOu7lR 0R43+ZRSgL/gh60MJsEtHEuvHHjWIsFfuNBJ9kQhmXwZ0RLVnK3EHQ71ArsnouE= =8yd8 -END PGP SIGNATURE- -- 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/blu0-smtp139fc4986c1b6d03bee5692b1...@phx.gbl
Re: Cambios en el kernel... ¿no más 686?
El 06/05/11 17:31, jmramirez (mas_ke_na) escribió: Juan Antonio escribió: 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. Buenas A mi me ha parecido interesante/instructivo, aunque no valga na, te doy un +5 XD Un saludo y buen finde Un saludo. Jajaja, gracias hombre. 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/4dc41ae9.5090...@limbo.ari.es
Re: Cambios en el kernel... ¿no más 686?
El 03/05/11, Camaleón noela...@gmail.com escribió: Hola, Me entero a través de Debian News¹ que se están preparando algunos cambios en el kernel que afectan a la rama i386 (y posteriormente a la amd64). En resumen, que a partir de la rama 2.6.39 van a dejar de empaquetar el kernel 686 y sólo estará disponible el kernel 686-bigmem (PAE+NX) que pasará a llamarse 686-pae. ¿Consecuencias? Pues que algunas personas tendrán que usar un kernel 486 en lugar del 686 ya que algunos modelos de micros no admiten PAE. ¹http://www.debian.org/News/weekly/2011/07/#lk-i386 Saludos, -- Camaleón -- Dado el actual nivel de tecnología, me parece (y remarco el 'parece') que lo único que podría verse afectado serían las netbook, pero dado que el uso que uno le da a esos cacharitos, a un núcleo 486 le sobra paño. Digo, por opinar 'na más JAP -- 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/BANLkTi=kj9wemqu54dcpkb+ir1c51jm...@mail.gmail.com
Re: Cambios en el kernel... ¿no más 686?
El Tue, 03 May 2011 08:29:28 -0300, Javier Argentina escribió: El 03/05/11, Camaleón escribió: Me entero a través de Debian News¹ que se están preparando algunos cambios en el kernel que afectan a la rama i386 (y posteriormente a la amd64). En resumen, que a partir de la rama 2.6.39 van a dejar de empaquetar el kernel 686 y sólo estará disponible el kernel 686-bigmem (PAE+NX) que pasará a llamarse 686-pae. (...) Dado el actual nivel de tecnología, me parece (y remarco el 'parece') que lo único que podría verse afectado serían las netbook, pero dado que el uso que uno le da a esos cacharitos, a un núcleo 486 le sobra paño. Digo, por opinar 'na más Hay portátiles (notebook) que se van a ver afectados (Pentium M -alias Banias-) o aquellos usuarios con máquinas virtuales que por decisión propia no tengan el PAE/NX activado, por ejemplo. Saludos, -- Camaleón -- 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/pan.2011.05.03.12.11...@gmail.com
Re: Cambios en el kernel... ¿no más 686?
On Tuesday 03 May 2011 12:48:58 Camaleón wrote: Hola, Hola! ¿Consecuencias? Pues que algunas personas tendrán que usar un kernel 486 en lugar del 686 ya que algunos modelos de micros no admiten PAE. Vale, pero eso no es ningun problema: He (Ben) also points out that these processors not supported by the 686- bigmem flavour seem to gain performance with the 486 flavour. Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Pero personalmente no he realizado ningún análisis de estos procesadores con diferentes nucleos. ¹http://www.debian.org/News/weekly/2011/07/#lk-i386 Se agradece la información Saludos, Saludos, -- Marc Olivé Blau Advisors marc.ol...@blauadvisors.com C/ Molí de Guasch, 10 baixos 1a, 43440 L’Espluga de Francolí (Tarragona) Tel. +34 977 870 702 Tel i Fax. + 34 977 870 507 www.blauadvisors.com -- 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/201105031334.24732.marc.ol...@blauadvisors.com
Re: Cambios en el kernel... ¿no más 686?
El Tue, 03 May 2011 13:34:24 +0200, Marc Olive escribió: On Tuesday 03 May 2011 12:48:58 Camaleón wrote: ¿Consecuencias? Pues que algunas personas tendrán que usar un kernel 486 en lugar del 686 ya que algunos modelos de micros no admiten PAE. Vale, pero eso no es ningun problema: He (Ben) also points out that these processors not supported by the 686- bigmem flavour seem to gain performance with the 486 flavour. El problema no es más que que cambiar de kernel. Pero te has parado en lo más interesante :-) (...) There is a small cost (up to about 0.1% of RAM) in the use of larger hardware page tables. En cuanto al rendimiento, pues tengo mis dudas (imagina un Core i7 con un kernel optimizado para un 486 que sólo puede ejecutar un hilo... no suena muy bien :-P). Recuerda que si el micro lo soporta, la elección de activar el PAE o no recae en el usuario. Ademas: Ben explains that only a very limited set of processors are not able to use the 686-bigmem flavour Sí, es cierto, no hay muchos, pero se olvida de las VM. Saludos, -- Camaleón -- 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/pan.2011.05.03.13.23...@gmail.com
