Re: Rendimiento del kernel PAE vs. 64 bits (Era: cambiar kernel 686 a amd64 ?)
2010/4/6 Camaleón <noelamac@gmail.com>
>
> El Tue, 06 Apr 2010 19:55:18 +0200, Javier Barroso escribió:
>
> > 2010/4/6 Camaleón:
>
> >> Pregunta para todos: ¿no debería el instalador utilizar de manera
> >> predeterminada el kernel "bigmem" si detecta que hay >4 GiB pinchados y
> >> que el micro admite PAE? :-?
>
> > Por lo visto es mucho más lento el kernel bigmem que el normal [1]
>
> Sí, algo de eso había leído en un mensaje de las listas del kernel¹. Esto
> es un extracto del mensaje de Linus T.
>
> ***
> "(...)
>
> 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.
>
> And when it makes the difference between doing IO or not doign IO (ie
> caching or not caching - when the dentry cache can't grow any more
> because it _needs_ to be in lowmem), you can literally see an order-of-
> magnitude difference.
>
> With 8GB+ of ram, I guarantee you that the kernel spent tons of time on
> just mappign high pages, _and_ it couldn't grow inodes and dentry caches
> nearly as big as it would have wanted to. Going to x86-64 makes all those
> issues just go away entirely."
> ***
>
> Desde luego da que pensar :-/
>
> > Aunque no tengo claro qué pruebas hay que hacer para verificarlo.
>
> Sí, visto desde fuera (aka: desde el punto de vista del usuario) suena
> raro que tener 8 GiB pueda ser un handicap en lugar de una ventaja. Yo
> también me pregunto hasta qué punto esa merma del rendimiento debido a
> las operaciones de mapeo de memoria es perceptible por un usuario de a
> pie :-?
>
Creo que tener 8GiB de memoria puede llegar a ser beneficioso, frente
a 4GiB, en muchas circunstancias, y aquí os dejo unos ejemplos, que yo
mismo he comprobado:
Primer caso:
Utilicemos brasero para grabar una imagen ISO de DVD de 4,3 GiB, este
tiene que realizar como mínimo 2 lecturas de los archivos que debe
almacenar en el ISO, esto es una vez para realizar el checksum de los
archivos, y otra para grabar. Con 8GiB, tan sólo hace una lectura,
pues los achivos se encuentran en la cache que tiene almacenada en
memoria. Si tenemos 4GiB de memoria, no podrá almacenarlo, por lo que
hace más lecturas a disco.
Segundo caso:
Durante la virtualización de máquinas, en el momento que excedemos los
4GiB físicos totales (memoria del host + memoria de las VM), tenemos
que utilizar la SWAP de disco, y aunque la tengamos repartida en
varios discos, siempre tendremos una penalización mucho mayor que
usando la memoria física.
Tal vez tengamos una penalización enorme de rendimiento, siempre que
excedemos el máximo de 8GiB físicos, y el sistema se vea forzado a
usar el swap de disco. Pero si en un sistema con 8GiB nos vemos
forzados a usar el SWAP, es más probable que un sistema con 4GiB con
una utilización de 4GiB de SWAP, se esté arrastrando materialmente.
El equipo anterior que tenía con 3 GiB de memoria, utilizaba siempre
la SWAP, mientras que ahora con uno de 8 GiB no lo usa nunca (tan sólo
en unas 3 ocasiones el sistema ha realizado uso del SWAP que ahora
tengo repartido en 3 discos diferentes). En una ocasión leí que un
sistema con el SWAP repartido en varios discos, funcionaba mucho más
rápido, en caso de tener que utilizar esta memoria.
Me preocupa mucho más el acceso a disco, el cual sigue teniendo una
lentitud exasperante cuando lo comparamos con la memoria.
Un saludo a todos/as.
Javier Silva.
>
> > Un saludo
> >
> > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383350
>
> ¹ http://lwn.net/Articles/356724/
>
> Saludos,
>
> --
> Camaleón
>
>
> --
> To UNSUBSCRIBE, email to debian-user-spanish-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> Archive: [🔎] pan.2010.04.06.18.19.32@gmail.com">http://lists.debian.org/[🔎] pan.2010.04.06.18.19.32@gmail.com
>
Reply to: