[eside-ghost] Penalización por HIGHMEM

Mie Jul 13 00:31:16 CEST 2005

Yo acabo de leer el articulo, reconozco que lo he tenido que leer unas 3 veces :P, para enterarme por donde van los tiros. Creo que te has liado un poco, yo lo volvería a leer. No está hablando de perder espacio físico, habla del modo de direccionamiento de los programas, cada programa tiene un espacio de direcciones virtual de hasta 4 Gb, la clave esta en los primeros parrafos.

=========================================================

32-bit architectures can reference 4 GB of physical memory
(2^32). Processors that have an MMU (Memory Management Unit) support
the concept of virtual memory: page tables are set up by the kernel
which map "virtual addresses" to "physical addresses"; this basically
means that each process can access 4 GB of memory, thinking it's the
only process running on the machine (much like multi-tasking, in which
each process is made to think that it's the only process executing on
a CPU).

The virtual address to physical address mappings are done by the
kernel. When a new process is "fork()"ed, the kernel creates a new set
of page tables for the process. The addresses referenced within a
process in user-space are virtual addresses. They do not necessarily
map directly to the same physical address. The virtual address is
passed to the MMU (Memory Management Unit of the processor) which
converts it to the proper physical address based on the tables set up
by the kernel. Hence, two processes can refer to memory address
0x08329, but they would refer to two different locations in
memory.

The Linux kernel splits the 4 GB virtual address space of a process in
two parts: 3 GB and 1 GB. The lower 3 GB of the process virtual
address space is accessible as the user-space virtual addresses and the
upper 1 GB space is reserved for the kernel virtual addresses. This is
true for all processes.

========================================================

Cada proceso que se esté ejecutando, tiene su propias tablas de direcciones, por defecto estas direcciones trabajan en un modo virtual (que en una arq de 32 bits son 4 Gb direccionables, lo que no quiere decir que los tengas claro), y aqui es donde entra todo el rollo, inicialmente este espacio virtual se separa (y hablamos de zonas de direccionamiento no de espacio físico) en 1 Giga para kernel space y 3 para user space. Lógicamente estas direcciones virtuales tienen que mapearse a reales en algún momento, por lo que en el peor de los casos, si el programa necesita más de 1Gb para kernel space pues no puede tomarlo, por que a pesar de que exista memoria física suficiente para ello, no tiene direcciones virtuales suficientes para establecer las equivalencias. Así que la primera solución que propone es partirlo en 2Gb y 2Gb  o 3 y 1. Otra manera más sofisticada parece que es la de dejar un trozo del giga dedicado al espacio de direccioes dedicado al kernel space sin usar (vamos que tu no la usas, pero que si que hay información relevante)

ome area of memory is reserved for storing several kernel data
structures that store information about the memory map and page
tables. This on x86 is 128 MB. Hence, of the 1 GB physical memory the
kernel can access, 128MB is reserved. This means that the kernel
virtual address in this 128 MB is not mapped to physical memory. This
leaves a maximum of 896 MB for ZONE_NORMAL. So, even if one has 1 GB
of physical RAM, just 896 MB will be actually available.

-----Y ahora viene la solución usar High Mem-------

2. HIGHMEM solution for using up to 4 GB of memory

Since Linux can't access memory which hasn't been directly mapped
into its address space, to use memory > 1 GB, the physical pages have
to be mapped in the kernel virtual address space first. This means
that the pages in ZONE_HIGHMEM have to be mapped in ZONE_NORMAL before
they can be accessed.

The reserved space which we talked about earlier (in case of x86, 128
MB) has an area in which pages from high memory are mapped into the
kernel address space.

Resumiendo, que no estas perdiendo memoria física, sino espacio direccionable en memoria virtual, que tienes que repartir entre zona usuario o zona kernel

Espero que te aclare algo, yo al menos es lo que he entendido y si he metido la pata por favor no dudeis en corregirme :D

Un Saludo Alex

On Tue, 12 Jul 2005 16:24:11 +0200
Cymo <gcymoril en gmail.com> wrote:

> Buenas. Como algunos sabréis (yo lo he descubierto hoy), debido al
> mapeo (¿ese palabro existe?) de memoria que hace Linux (el kernel, me
> refiero) [1], si tienes 1GB de RAM como es ahora mi caso, resulta que
> solo te utiliza 896M. Es decir, 128M se van al caraio.
> 
> No acabo de entender muy bien por qué ocurre todo esto (arqui sucks)
> pero, si activas la opción de HIGHMEM y la de 4GB en el kernel,
> entonces ya te deja usar TODA la memoria (partida en dos cachos: 896
> de LOWMEM y 128 de HIGHMEM).
> 
> En fin, que unos dicen que es mejor desactivarlo y sacrificar los
> 128MB [1], y otros que es mejor activarlo porque no tiene impacto
> sobre el rendimiento.
> 
> ¿Alguien sabe algo más en profundidad para poder aclararme? Quiero
> dedicar mi vida a otras cosas que no sea el "make bzImage".
> 
> Cymo
> 
> [1] http://kerneltrap.org/node/2450
> Nota: hay varios comentarios en ese artículo que dicen que es
> "misleading" (no tanto como incorrecto, sino peor :D)
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost

-- 
   Alejandro López Monge
   Universidad de Deusto
   Aptdo. 1
   48080 - Bilbao (SPAIN)
   Ext: 2919
   e-mail: kodemonk en emasterminds.net