Day: 11 July 2006

Or, A Tale Of Why Not To Fiddle.

I mentioned in a recent entry that I’d reinstalled my laptop, and also mentioned a few of the things I changed after the reinstall.

One thing I didn’t mention was changing the hdparm settings. By default, the system had DMA enabled, but not ‘unmask irq’, ’32-bit IO support’ or ‘multiple sector I/O’. I edited /etc/hdparm.conf to turn these on and set MultiSector IO to 16. I’ve been using these settings for a while – before reinstalling this laptop, and I’d copied them in turn from an older machine where I’d done measurements on each option to find the best setup.

I also mentioned tweaking some of the xorg.conf settings. In particular, AGPMode and AGPSize. Eric Anholt commented that probably neither of these is a good thing to do – that AGPMode might provide some speed improvement in 3D rendering, but usually not much, and can also destabilise some systems when turned too high. I had thought that AGPSize sets the maximum amount of System RAM the X server can allocate for AGP Memory to talk to the graphics card, and that this was dynamically allocated when needed. Eric tells me, however, that the entire AGPSize RAM is reserved at server startup.

About 3MB is used for the buffers to communicate with the card, and the rest is kept as texture memory. Since the card in this laptop already has 64MB onboard, it’s unlikely (with the 3D apps that I run) that it will overflow, which means that providing an extra 56MB of RAM for this purpose is pointless, and a waste of good RAM. I tried a bunch of 3D apps that I regularly use (Togra, q3a, Tron) and couldn’t discern any performance difference (naked eye only – no fps tests). In the end, I took both settings back out and let X.org use its defaults again.

The hdparm changes and the xorg.conf settings were the only system things I’d changed from the default install, and I knew that hibernation had worked once before changing them, but didn’t work later. I figured maybe one of the settings might be the culprit, so I also put the hdparm settings back to the defaults – and hibernation worked again!

After some test cycles, I found that setting MultiSector IO on breaks the hibernate for some reason – turning it back off instantly makes hibernate work flawlessly. Interestingly, some googling for this problem seems to indicate that at some point in the past at least one ThinkPad model needed multi-sector IO turned ON in order to hibernate.

While I was at it, I figured I should actually run some tests and see if the other 2 changes (-c1 and -u1) actually made some difference. I tested using bonnie, and found that -c1 seemed to provide a modest increase in disk throughput. -u1 seems to decrease io throughput slightly, but (going by the hdparm manpage) allows better system responsiveness during heavy IO by allowing other interrupts to be processed during a disk interrupt. Enabling -u on some systems can be really bad (read: filesystem corruption), which is why it is off by default. I decided to leave both these settings turned on.

The moral of the story of course is not to blindly copy settings or change them without actually measuring and having a good reason to – the same rules we use when performing any optimisations. Alternatively, the moral is to be a X/kernel hacker and know what’s best already 🙂