Mailinglist Archive: opensuse-es (1727 mails)

[Rafa Grimán <rafagriman@xxxxxxxxx>]

Hola :)

El Viernes, 12 de Mayo de 2006 17:08, Victor Hugo dos Santos escribió:
> 2006/5/12, Rafa Grimán <rgriman@xxxxxxx>:
> > Hola :)
>
> [...]
>
> > Pues resulta que al final la culpa fue mía 0:) El hardware estaba mal
> > configurado !!! Me explico: se debe asignar 1 CPU por cada puerto de 1
> > GigE que se tenga.
>
> como lo haces ??? por el kernel ??  o la BIOS ??? por algun hechizo ???
> la verdad es que nunca lo tenia escuchado !!!


Bueno, esto tiene dos formas ... que además van juntas ;)

Por un lado tienes un sistema que por hardware (generalmente un chip) te 
asocia los dispositivos físicos, los interconecta. Esto suelen ser los 
chipsets, en nuestro caso se llama SHUB. Este chip tiene la misión de 
interconectar los diferentes dispositivos. En nuestro caso (SGI), no tenemos 
"ordenadores" sino que lo que tenemos son placas base que tiene "algo": CPUs, 
memoria, I/O, el SHUB este y un conector llamado NUMALink. Estas placas base 
van metidas en un "enclosure" que parece un ordenador, a todo esto es lo que 
llamamos brick. El NUMALink lo que permite es conectar todos estos bricks y 
el SHUB lo que hace es conectar o establecer rutas entre los diferentes 
dispositivos que hay en cada brick.

El SHUB lo que hace es que si tienes un brick que tiene todo (CPU, memoria, 
I/O), asocia estos dispositivos I/O a las CPUs y memorias más cercanas.

Bueno, como hablamos de chips, también hay que tener en cuenta que hay un 
firmware ;)

En el lado SW, tenemos básicamente dos cosas:
	- scheduler
	- un comando (creo que era tasksel)

El scheduler distribuye cargas y con el comando puedes asociar tu mismo los 
procesos. En nuestro caso, como son drivers, hacerlo a mano no es lógico por 
lo que nos basaríamos en el scheduler y en el SHUB+NUMALink.


> > El problema con sistemas NUMA es que el sw (kernel o no) "van"
> > a la CPU que más cercana está. En mi caso había 5 puertos de red GigE
> > en el mismo brick asociadas a 2 CPUs. Luego había un cuello de botella
> > porque los drivers de las 5 tarjetas iban a estas 2 CPUs :( El resultado
> > de esto era: - cuello de botella en los buses PCI
>
> mmm.. algo imaginaba referente a esto !!! ya que como comente, los
> buses PCIs eram compartidos, al menos para la maquinas que nosotros
> simples mortales usamos, no se las tuyas ya que nunca contestaste
> sobre esto.


Bueno, en nuestro caso, tenemos 2 buses PCI en cada placa, con dos ranuras 
cada bus. Según esto, podemos pinchar 4 dispositivos PCI. Esto lo hacemos 
rara vez debido a lo que dices. En el caso que me pasó, sí compartí 1 bus 
entre 2 dispositivos PCI porque ambos eran tarjetas de red y pensé, "Bueno, 
como una de ellas no se usa (no tiene cable de red y no está configurada), 
pues nop habrá pérdida de rendimiento" ... Eso me pasa por pensar ;)


> >         - las 2 CPUs estaban al 100% y el restante no hacía gran cosa
>
> mm. me extrana ya que imaginaba que se compartian la carga !!!! y es
> como la primera vez que escucho que una tarjeta PCI sartura toda una
> CPU.


El problema en este caso es que en lo que se está gastando CPU es en 
interrupciones y (como comenta Carlos en el correo anterior) el tema de 
TCP/IP-Ethernet. Hasta donde yo sé, esto no se puede distribuir ya que la 
latencia sería mayor de lo que debería ser y se perdería rendimiento. 
Hablándolo con otras personas, me han comentado que también influye el 
scheduler de Linux y que son cosas en las que se está trabajando :)


> > Pues eso, muchas gracias a todos por las ideas ;)
>
> Gracias a usted por compartir conozco estas configuraciones
> "utopicas", que posiblemente nos demorara mucho en conocer
> personalmente.


:)

   Rafa

-- 
50% of all statistics are inaccurate.

OpenWengo: rgriman