Intel Feature Fragmentation

Intel randomly enabling and disabling features across their processor lines drives me crazy. I want to upgrade my fanless Panasonic R3 subnetbook —based on a Pentium M 1.2 GHz with a max TDP of only 5.5W(!)— to one with a processor supporting a 64-bit instruction set, Intel VT-x for some light virtualization work with KVM, and as low power as possible. I started by researching the Intel Atom processor family, hoping that Intel would have made VT-x a standard by now.

My hopes quickly got crushed.

Read this list of processors supporting VT-x: it doesn't even make sense. The lowest power Atom processors Silverthorne and Lincroft (Z5xx, Z6xx) support VT-x but are 32-bit, while the slightly more power hungry ones Diamondville and Pineview (N2xx, 2xx, 3xx, N4xx, D4xx, N5xx, D5xx) are 64-bit, but do not support VT-x.

There is really no choice for me but to aim at the Celeron or Core processor families. After some more research I established a list of the lowest power 64-bit processors, VT-x-enabled, and based on the Nehalem microarchitecture. Because these processors have the CPU and the GPU on the same chip, the TDP includes both. I restricted myself to those with a max TDP of 18W. The next step in terms of power consumption is 25W, then 35W, which is too high to my taste. I also excluded Core i7 processors which are just more expensive i5 models with more cache or higher Turbo Boost frequencies, which is not worth the premium in my opinion.

Now remains to find decent subnetbook models using the above processors...

mrb Tuesday 31 August 2010 at 01:19 am | | Default | No comments
Used tags: , , ,

getdents() And lstat() Race Condition

I never thought I would ever witness this, as an end-user of a Linux system, from a normal shell session: 

$ ls -l
ls: cannot access index.pdf.part: No such file or directory
total 2672
drwx------  2 mrb mrb      91 Aug 13 20:27 .
drwxr-xr-x 53 mrb mrb    4096 Aug 13 20:26 ..
-rw-------  1 mrb mrb 2610918 Aug 13 20:27 index.pdf
??????????  ? ?   ?         ?            ? index.pdf.part
$ ls -l
total 2672
drwx------  2 mrb mrb      91 Aug 13 20:27 .
drwxr-xr-x 53 mrb mrb    4096 Aug 13 20:26 ..
-rw-------  1 mrb mrb 2610918 Aug 13 20:27 index.pdf

This is a race condition between getdents() and lstat() ! I was using Firefox to download a file called index.pdf. The browser creates a 0-byte index.pdf file, then downloads the data to the temporary file index.pdf.part and, when done, renames it to index.pdf. I just happened to run "ls -l" right before the rename, so ls obtained the 2 directory entries via getdents(), but by the time ls tried to lstat() the second file, the rename had already been performed, so the lstat() call failed with ENOENT.

The first thought that flashed to my mind was filesystem corruption, but I immediately re-ran ls and it ran fine. This race condition is probably easy to reproduce with an automated tool, especially on a loaded system under a random I/O workload, but the fact it happened to me on a virtually idle system is very surprising :-)

mrb Friday 13 August 2010 at 8:55 pm | | Default | One comment
Used tags: ,
| |