Hola :) El Wednesday 17 September 2008, Juan Erbes escribió: [...]
Eso tendrias que decirselo a Tony Luck, que es el que escribio el articulo. ( is a principal engineer at Intel. Since graduating from Warwick University, Tony Luck has worked on just about every UNIX variant (V6 to SVR4, Genix, Solaris, HP-UX, and Linux) on a wide variety of microprocessor architectures (m68k, m88k, ns32k, sparc, pa-risc, Itanium). For the past seven years Tony has been at Intel and is currently the Linux maintainer for the Itanium architecture).
No he dicho que el art�culo sea incorrecto, s�lo aclaraba un poco (resumiendo) para los que no hablan/leen ingl�s o no quieren leer el art�culo entero.
Pero vos bien sabes que hay microprocesadores que vienen con NUMA "de fabrica" con el controlador de memoria integrado, y otros que no lo traen, y aun estan en fabricaci�n.
NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU. Es m�s, en el documento, dice esto mismo:
"A NUMA system connects processors and memory banks this way: - Connect some processors directly (or local) to some memory banks. - Provide a forwarding method to access data in memory banks for processors not directly connected to memory banks."
Que es precisamente lo que yo he puesto en el correo anterior.
Como he dicho antes, hemos estado hacinedo esto durante a�os sin necesidad de tener el controlador de memoria en la CPU. Que el controlador de memoria est� en la misma CPU ayuda en temas de latencias, por ejemplo, pero no por ello significa que sea NUMA.
Que NUMA no tiene nada que ver con integraci�n del controlador memoria en la CPU?
Y que significa entonces el parrafo del articulo que dice: "Today, even a single board computer may be NUMA, when processors have integrated memory controllers. "????
Traducido, viene a ser algo como: Hoy en d�a, incluso un ordenador con una sola placa madre puede ser NUMA, cuando los procesadores tienen integrado los controladores de memoria. http://www.linux-mag.com/id/6868
No niego lo que tu dices, pero sin el controlador integrado en el micro, es algo mucho mas complejo de implementar, mientras que en un mobo decente, con 2 zocalos para micros y 2 Opterons (simple o doble core, o hasta cuadruple), ya se implementa NUMA, sin ningun agregado, ni hardware extra�o. http://www.supermicro.com/Aplus/motherboard/Opteron/8131/H8DA8.cfm
Es curioso, porque los farbicantes que ofrecemos NUMA desde hace muchos años (y somos unos cuantos fabricantes y NUMA no es nada nuevo) llevamos haciendo esto con Itanium desde que, por ejemplo, salió el Itanium (que NO tiene el controlador de memoria en la CPU). SGI, HP, Bull, Fujitsu usan Itanium, otros fabricantes (IBM) usan otros procesadores. Antes de Itanium, por ejemplo, SGI utilizaba MIPS en los sistemas NUMA. En el caso de SGI, te podemos montar un NUMA con una placa que tiene dos sockets Itanium dual-core cada uno y ninguno de ellos tiene controlador de memoria en la CPU. Y, en nuestro caso, tampoco añadimos "hardware extraño", como pones en tu correo. Es más, el tener el controlador de memoria en la propia CPU puede ser un inconveniente en determinados modelos de NUMA ya que te obliga a meter un blade (o MoBo) _CON_ la CPU aunque sólo quieras ampliar memoria. Ya que es la CPU la que tiene el controlador de memoria. Es decir, tengo una MoBo (o blade) con 2 sockets y 4 ranuras de expansión de memoria para cada socket. Lleno las 8 ranuras de expansión con RAM. Si quiero añadir más RAM, pueden ocurrir dos cosas: - si tengo procesadores _SIN_ controlador de memoria, añado otro blade (o MoBo) que _SÓLO_ contiene ranuras de expansión de RAM y amplío la RAM, no es necesario ampliar el número de CPUs - si tengo procesadores _CON_ controlador de memoria, añado otro blade (o MoBo) que contiene ranuras de expansión de RAM _Y_ sockets de CPU. Luego me veo _OBLIGADO_ a ampliar el número de CPUs a la vez que amplío la RAM, cosa que no quiero porque, por ejemplo, el sw que estoy ejecutando se licencia por CPU (Oracle, por ejemplo) Luego tener el controlador de memoria en CPU me sale más caro porque al ampliar RAM, tengo que ampliar CPU (las tengo que pagar/comprar) y tengo que pagar las licencias adicionales del sw que esté ejecutando (en caso de que sea así el caso). Pero mínimo, tengo que pagar nuevas CPUs que _NO_ quiero y _NO_ necesito. Esto también aumenta el consumo eléctrico, la producción de calor, ... Conozco varios casos reales que te pondría como ejemplo de un sistema NUMA que tiene este problema. Te voy a poner uno sólo: un cliente corriendo Oracle quiere ampliar RAM (tiene 256 GB de RAM y 16 CPUs). El fabricante le dice que para ampliar RAM, tiene que ampliar CPUs, concretamente, tiene que añadir otras 16 CPUs. Resultado: - tiene 32 CPUs de las cuáles _SÓLO_ usa 16* - está pagando 32 licnecias de Oracle, aunque sólo usa 16 CPUs* - el sistema ha ampliado mucho el consumo eléctrico - el sistema ha ampliado mucho la producción de calor - han tenido que ampliar el sistema de refrigeración Lo bueno de tener el controlador de memoria en la CPU: menor latencia, por ejemplo. Luego clientes que ejecutan aplicaciones multihilo que requieran una baja latencia (y que no se licencien por core) se verán favorecidos. Las cosas no son 100% buenas o malas. Depende de la situación en la que te encuentres. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org