How Intel/AMD (inadvertently) fixed GNU Hurd

04 09 2011
Last Friday, on Hurd's IRC channel at freenode, we've accidentally noticed some machines were able to run certain operations on Hurd as KVM guest up to 10x faster than others. As antrik correctly guessed, this is the effect of Intel's Extended Page Tables, which allow the guest operating system to deal with it's own page faults. I suppose AMD's Rapid Virtualization Indexing could have a similar effect, but I don't have the hardware to be able to test it (please write to the mailing lists if you've been able to check it).

Since most people (including myself) are running Hurd in a virtualized environment, having the ability of taking advantage of this circumstance by moving to hardware with this technology supposes a great improvement, heavily reducing compilation times and increasing the interactivity of the entire system.

Let's see an small example of the difference between running with and without EPT.

Running without EPT (modprove kvm-intel ept=0):
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 2.08 s, 126 MB/s

And with EPT:
root@debian:~# dd if=/dev/zero of=/dev/null bs=256k count=1000
1000+0 records in
1000+0 records out
262144000 bytes (262 MB) copied, 0.23 s, 1.1 GB/s

I think there will be interesting times for GNU Hurd.


How device size affects disk performance in Linux

09 02 2011
While running some tests in a client's environment, we've noticed reading from a partition of a multipath device was considerably slower than reading from its parent node:

[root@none]# dd if=mpath4 of=/dev/null bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 8.92711 seconds, 120 MB/s

[root@none]# dd if=mpath4p1 of=/dev/null bs=1M count=1024 skip=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 17.5965 seconds, 61.0 MB/s


We asked to client support of a well-known GNU+Linux vendor, and they indicated that this behavior was "expected", since this kind of partitions were created by stacking a dm-linear device over the original multipath node. I wasn't satisfied by this answer, since AFAIK dm-linear only did a simple transposition of the original request over an specified offset (the beginning of the partition), so I decided to investigate a bit further on my own.


Continue reading "How device size affects disk performance in Linux"


DRM y Software Privativo van de la mano

09 11 2010
Navegando por reddit, me he encontrado con esta entrada en la que un usuario se queja de que no puede reproducir un Blue-Ray legítimamente adquirido, ya que está utilizando como salida de vídeo una TV conectada al puerto HDMI de su portátil (un Macbook Pro).

En dicha entrada se comenta cómo los fabricantes se perjudican a sí mismos con este tipo de prácticas. Ciertamente es un aspecto a destacar, pero también es importante tener en cuenta que dichas prácticas no serían posibles sin que existiese cierto Software Privativo que haga efectivas las limitaciones artificiales impuestas por los fabricantes. Y donde hoy es impedir que se reproduzca un contenido si se visualiza en una TV sin HDCP, mañana podría ser cualquier otra prohibición igualmente ridícula y arbitraria.

Y es que este es uno de los principales motivos por los que Richard M. Stallman inició el proyecto GNU hace 25 años: impedir que los fabricantes tuvieran la capacidad de decidir sobre lo que el usuario puede o no hacer con su computadora. El Software Libre, como su propio nombre indica (al menos en su denominación castellana, más precisa que la anglosajona), trata sobre la libertad, y no sobre la gratuitidad, matización que con frecuencia se suele pasar por alto.

Si en atención a nuestra comodidad entramos en el jardín vallado que nos presentan y damos por buenas este tipo de prácticas (y entre ellas podemos incluir también modelos de distribución de software como el AppStore), le estamos dando vía libre a los fabricantes para que tomen el control de nuestros dipositivos y decidan por nosotros lo que podemos hacer con ellos. Y los peligros que esto entraña en una sociedad donde las TI están presentes a todos los niveles (y cada días más), son impredecibles.


Linux: Bug in the nozomi driver

05 12 2009
If you have a nozomi based 3G PCMCIA modem (like the Option models from Movistar Spain), you'll probably noticed that, since kernel version 2.6.29, you can no longer establish an Internet connection with it. While it properly answers to AT commands, when the pppd daemon tries to talk to the other side, it simply hangs with no response.

If this is your case, you might be interested in taking a look at this bug (13024). Or, if you're in a hurry (and somewhat brave ;-), you might want to try something like this:

--- nozomi.c.orig 2009-12-05 22:57:43.000000000 +0100
+++ nozomi.c 2009-12-05 22:57:54.000000000 +0100
@@ -1626,10 +1626,10 @@

dc->open_ttys--;
port->count--;
- tty_port_tty_set(port, NULL);

if (port->count == 0) {
DBG1("close: %d", nport->token_dl);
+ tty_port_tty_set(port, NULL);
spin_lock_irqsave(&dc->spin_mutex, flags);
dc->last_ier &= ~(nport->token_dl);
writew(dc->last_ier, dc->reg_ier);




CentOS 4.6 sobre VirtualBox 1.6.0

18 07 2008
Si has intentado instalar CentOS 4.6 sobre VirtualBox 1.6.0, probablemente te habrás encontrado con una desagradable sorpresa; tras la instalación, durante el primer arranque desde el disco duro, el sistema se queda congelado. El problema, aparentemente, es que VirtualBox sigue teniendo problemas lidiando con ciertas operaciones de la arquitectura x86, en este caso con la inicialización del soporte multiprocesador (MPS o ACPI, falla de las dos formas).

Puedo entender que, al contrario que otras soluciones de virtualización, VirtualBox todavía no pueda mostrar al sistema operativo varios procesadores, pero que no soporte las estructuras de SMP, aunque sea dando soporte a 1 sólo procesador, me parece bastante lamentable.

En el caso de CentOS (y supongo que otros sistemas GNU/Linux), en el primer arranque deberos entrar el menú online de GRUB para seleccionar el núcleo sin soporte multiprocesador y su initrd.img correspondiente. Una vez arrancado el sistema, modificaremos el archivo /boot/grub/menu.lst para hacer permanente este cambio.