Matthew Garrett

Fri, 09 May 2008 15:25:11 GMT

My previous entry was somewhat misleading in one respect - the discussion of the power consumption of a downclocked processor. The problem is that nowadays, halving your CPU frequency doesn't halve the power consumption (see the figures in Arjan's slides from OSCON last year, for instance). I'm assuming that this is due to the cache size on modern hardware being sufficiently large that it dominates the power consumption of the processor. Dropping the frequency doesn't reduce the amount of power required to keep the contents of the cache alive, so the saving is less than you'd expect. Deeper C states disable the cache and save much more power.

So, if halving your speed means everything takes twice as long but doesn't even halve your power consumption, what's the point in having P states at all? There's a certain amount of latency and power involved in moving between C states, and if the choice is between rapidly cycling between full speed and C4 or just sticking at low speed and maybe dropping into C1 or C2, then executing code at the lower performance state may be beneficial. The ondemand governor takes this into account by looking at the amount of load on the processor over time, so if this doesn't hit a threshold value it'll assume that you're better off staying at the lower performance level.

Thu, 08 May 2008 23:19:14 GMT

Modern CPUs are great. They have all sorts of advanced power saving features, which is one of those nice cases where everyone can save money, gain performance and claim environmental credentials at the same time. Everyone's a winner.

Well. Everyone's a winner as long as your software doesn't suck.

I've talked about the benefits of the tickless kernels and reducing wakeups and spending longer in deep C states before, so if you don't know about them then go and read that first. This time I'm going to focus on a different level of hardware, and a different level of suck.

For a long time, laptops supported changing the speed of processors when switching between AC and battery. CPU power consumption is proportional to frequency, so dropping the frequency meant a longer battery life. Of course, it also meant that it took longer to get anything done - the reason this was still a win was because CPUs in those days consumed just as much power when idle as when running. Transmeta introduced a technology called Longrun with their Crusoe processors, bringing the ability to drop both the frequency and the voltage of the CPU simultaneously. With power consumption being proportional to the square of the voltage, even a small drop resulted in worthwhile power savings. As the only really worthwhile thing Transmeta brought to the x86 world[1], this was unsurprisingly ripped off by everyone else. Intel introduced their Enhanced Speedstep, AMD gave people PowerNow and VIA have Longhaul.

Obviously, reducing the frequency of the CPU increased battery life. Everyone's happy?

No[2].

The problem is that nowadays, processors don't consume as much energy when they're idle as when they're running. The aforementioned C states mean that an idle processor consumes a tiny percentage of a loaded one - an ultra-low voltage Intel part will draw on the order of a watt. Executing code, even at the lowest voltage and frequency, will draw far more power. Obviously, we want to keep the processor idle for as long as possible. The easiest way to do this would be to never run anything, but that's not a real option. The alternative is to run when we have to, but make sure that we get it over with as quickly as possible so we can return to the idle state. Counterintuitively, that means switching to the highest voltage and frequency, executing the code and then dropping back into the idle state. By going faster, we save power[3].

In summary, the only sensible way to use a CPU is to run it as fast as possible in order to let it idle as much as possible, and drop the frequency and voltage when it's not doing anything. The. Only. Sensible. Way.

Some people write software that lets you choose different power profiles depending on whether you're on AC or battery. Typically, one of the choices lets you reduce the speed of your processor when you're on battery. This is bad. It is wrong. The people who implement these programs are dangerous. Do not listen to them. Do not endorse their product and/or newsletter. Do not allow your eldest child to engage in conjugal acts with them. Doing this will reduce your battery life. It will heat up your home. It will kill baby seals. The sea will rise and your car will float away. If you are already running it, make sure that it always sets your cpufreq governor to ondemand and does not limit the frequencies in use. Failure to do so will result in me setting you on fire[4].

The only legitimate reasons for limiting the speed of your CPU are to avoid overheating (which should be fixed in the kernel, really - having userspace in charge of ensuring the continued functioning of the machine is madness) or to make the machine quieter. And if you want your machine to be quieter, there should be a tickbox marked "Reduce performance in order to reduce noise" or something, which would take into account all the sources of heat in your machine rather than just your CPU. Encouraging the managing of acoustic levels by asking users to restrict the functionality of their CPU is just another way of saying "Look! We suck!". Letting the user choose a specific CPU governor or a specific frequency is not a useful thing to do. Don't do it unless you want to see dead kittens. Delivered by UPS.

[1] And, presumably, whatever else Intel and everyone else ended up licensing off them which resulted in their reinvention as an IP company rather than a CPU one, but that's just not interesting to me.

[2] Even ignoring the people that are unhappy for entirely unrelated reasons, such as injured toenails or the brutal murder of their family

[3] There's a corner case here, which is a system that is always entirely CPU bound. Say we halve the CPU's speed. Along with the voltage drop, that gets us down to about 20% of the original power consumption. Of course, it now takes twice as long to do anything and your screen, RAM, hard drive, chipset and so on are still drawing power, so will end up costing you twice as much power as they would have done if you'd run at full speed. If you do the maths, it works out that you save power if your processor's full-speed power consumption is more than 1.7 times that of the rest of the platform. In the real world, things are made more complicated by the rest of your platform consuming more power if you're working over a longer period of time - your hard drive is going to end up spending more time spun up, your memory bus is going to be active for longer and so on. You're basically not going to hit this case.

[4] While the burning of your body will result in carbon emissions, the reduction in power usage should offset this in the long run

Tue, 06 May 2008 22:48:06 GMT

One of the advantages of working in a biology lab is getting deliveries of stuff in dry ice and getting to play with the dry ice afterwards. Sadly, while dry ice is clearly very cool (a-ha ha ha ha ha (dies)) it makes a lousy way of cooling down your drinks[1]. With a latent heat of sublimation of merely 199kJ/kg, CO₂ draws less energy out of the liquid than ice's latent head of melting of 334kJ/kg. That's easily dealt with by using larger blocks of dry ice, but the fundamental problem seems to be that most of the sublimed CO₂ boils straight out of the glass and just gently cools the atmosphere instead. Maybe ethanol cubes are the way forward.

[1] Much like Red Stripe, it is also a lousy fabric softner.

Sat, 03 May 2008 23:50:50 GMT

It turns out that I was insightful four and a half years ago, and I should damn well listen to my own opinions.

Sat, 03 May 2008 14:41:56 GMT

People rarely ask me about my amazing ability to remove fruitfly ovaries in under 10 seconds. "This skill makes me strangely attracted to you" they then inevitably fail to add, thus giving the lie to claims that a PhD in biology is a great way to impress women. In order to avoid future social embarrassment I have therefore decided to provide a step-by-step guide to removing ovaries from any fruitflies you may have to hand.

Feed your fruitflies. Fruitflies like yeast, so give them a pile to munch on. A well-fed fruitfly is a happy fruitfly.
A happy fruitfly is a fertile fruitfly, and has bigger ovaries. Since fruitflies are small, this makes your job easier.
Knock your fruitflies out with carbon dioxide. When doing this, ensure that you don't knock yourself out with carbon dioxide.
Separate your fruitflies into male and female flies. Female flies have larger abdomens and striped posteriors - male ones are thinner and have solid black markings.
Dispose of the males. They don't have ovaries. Local laws may make it awkward for you to release animals from laboratory environments, so dump them into a bottle of ethanol. They'll probably die happy, to the extent that fruitflies can really be happy.
Etherise the female flies. When identifying ether, try not to do so by smelling it.
Once the female flies are thoroughly dead, transfer one to a small watchglass containing a quantity of phosphate buffered saline with a small quantity of detergent in it. Place this under a low magnification microscope.
Grip the neck of the fly with a set of needle-nosed tweezers. Grip the very rear of the fly with another set of needle-nosed tweezers.
Slowly move the tweezers apart. If you are lucky, the abdomen will split and you'll start pulling out internal organs. If you're unlucky, the head will come off. In this case you should move the first set of tweezers further down the body and try again.
Continue pulling out internal organs until you find two objects that look like bunches of bananas. These are the ovaries, with each "banana" being an egg chamber containing an egg and associated support cells.
(If your fruitfly contains no ovaries, it's not a female. Try again)
Carefully separate the ovaries from the other chunks of tissue that are stuck to them, and transfer the ovaries to a tube containing phosphate buffered saline.
Repeat until you run out of flies. Note that towards the end, it will become tempting to just tear the flies into small pieces rather than removing their ovaries. Bear in mind that the aim is to obtain fruitfly ovaries, not to kill flies. There are much easier ways of doing the latter.
Dispose of the remaining bits of flies in accordance with any relevant legislation. Do not throw remaining bits of flies at coworkers.
Fix the ovaries in formaldehyde and suspend in methanol. Freeze at -20°C.

See? It's all very easy.

(Note: This protocol involves chemicals known by the state of California to cause cancer, birth defects and general fucked-upness. Do not ingest methanol unless you want to demonstrate competitive inhibition in the form of a bottle of vodka. Value of fruitfly ovaries may go up as well as down. Do not taunt fruitfly ovaries)

Tue, 29 Apr 2008 00:36:39 GMT

Why has the phrase "Zuckerberg's famous pig" not appeared on the internet up until this point?

Mon, 28 Apr 2008 21:59:19 GMT

As Adam mentioned, Facebook has a new feature to let you search for the frequency of various words used in communication over time. You probably need to be a Facebook user to see any of these, but interesting ones include never drinking, rape (tends to peak on Sundays) and dead, which demonstrates the somewhat bizarre effect of Heath Ledger on the internet.

Thu, 24 Apr 2008 11:08:21 GMT

Yes, because getting offended when people voice their opinion that women belong chained to the sink or that (insert race here) are genetically inferior or (insert sexual practice here) indicates dangerous deviancy is a clear sign of lack of personal integrity and self-awareness.

I give up. Life is significantly better at parody than I am.

Thu, 24 Apr 2008 02:25:37 GMT

Dear Russell,

You <------------------------------------------>Perth<---------------------------------->The point

Kthxbi,

Matthew

Updated: This makes me think that there ought to be a moon somewhere in the above diagram.

Wed, 23 Apr 2008 16:31:46 GMT

Note that by "Enable Touchpad" it also means "Make my touchpad mouse buttons work". For machines that are only equipped with a touchpad (and, indeed, some that are equipped with a trackpoint as well - it depends on how it's wired up), the only option is to figure out that the space bar or enter will save you.

(Ubuntu-specific change, introduced in 8.04)

Wed, 23 Apr 2008 00:39:49 GMT

Oh, and for the love of christ. Australian cultural norms are the correct standard for determining what's acceptable for posting on a site that has clear guidelines against offensive content? Baby Jesus cries with as much pain as if he'd been suddenly violated in an utterly inappropriate way.

Wed, 23 Apr 2008 00:12:02 GMT

...

Leaving aside the obvious failure (asking women to classify themselves into those who are happy to have their breasts groped and those who aren't - and yes, that is the effective choice, since refusing to participate will result in people making conclusions about which of those categories you fit into), there's the whole "open-source breast" thing.

Creating copyrightable works is a choice. Having breasts is not[1]. Attempting to equate the two is not reasonable. Applying "open-source" to things that are not directly comparable to copyrightable works is like applying "Darwinism" to things that are not directly comparable to natural selection operating upon living things. Discussing Darwinistic politics is likely to result in people concluding that you're either a libertarian fuckloon or blame atheists for the death of your cat. Discussing open-source breasts is likely to result in me stabbing you in the fucking eye. Don't make the baby Jesus cry when he sees your horribly mutilated face. Just accept that open source is a useful licensing model, not an entire way of life.

Or: get your hands off my adjective or you'll find my hands on things you really don't want groping, whether you're wearing a badge or not.

(And yes, I realise that this is not the offensive aspect of things. This says it better than I could)

(Previously)

(Previously previously)

[1] There's a set of basically uninteresting exceptions. And by "uninteresting" I mean "If you are trying to argue over this, then you are missing the fucking point"

Why Linux claims to be Windows

Sat, 19 Apr 2008 19:57:53 GMT

Section 5.7.2 of the ACPI specification provides for a method called _OSI. Platform firmware can query for various interfaces, which allow it to tweak its behaviour depending on the interfaces that the OS supports. Linux claims to support the following interfaces:

Windows 2000
Windows 2001
Windows 2001 SP1
Windows 2001 SP2
Windows 2001.1
Windows 2001.1 SP1
Windows 2006

which all correspond (unsurprisingly) to different versions of Windows. Linux used to be in there, but was removed for reasons I'll get into later.

The typical way in which this feature is used by a platform is by querying each of the interfaces in turn, starting with the most recent a firmware is aware of. After the first match, a value will be stashed somewhere and used elsewhere in the firmware when making certain decisions. An example of this may be only enabling certain devices (such as the HPET) if the OS claims to support Windows Vista.

As I mentioned, recent versions of Linux no longer claim to support the Linux interface. There's a couple of reasons for this. Firstly, some platforms break if they're told that they're running on Linux. It's usually an entirely untested codepath. Secondly, the whole point of the _OSI method is to provide the platform with information about the interface supported by an OS. "Linux" is too coarse grained - we make no guarantees that the interface between the OS and the platform will remain constant. "Linux 2.6.25" isn't all that much better, since distribution patches may alter the behaviour and BIOSes would become specific to a given kernel version. We could have something like "Linux ABI 1" and then bump that every time we altered the behaviour of the kernel in this respect, but this would become unwieldy fairly quickly (what would count as an ABI breaking change?)

So what kind of interface can we claim to provide? The sad truth of the matter is that most vendors will only test their code against Windows, and that as a result Windows provides the de-facto specification for OS/platform interaction. We could skip claiming to be Windows, but (in the best case) that means that the system will assume it's working with an OS that supports no advanced features. Rather than getting support for brightness changes being handled by the OS, we get stuck with SMM traps and unexpectedly missing time. If we want hardware to work to its full potential, we need to claim to be a recent version of Windows.

Does this mean the entire _OSI mechanism is useless? Not really. It's still useful for providing information about supported functionality. One example used in the spec is whether or not the OS implements the ACPI 3.0 thermal model. Another obvious (but unspecced) example might be whether or not the video opregion spec is implemented in the OS. _OSI strings which explicitly advertise the existence of advanced functionality are something that should be specified and encouraged. What they shouldn't be used for is as a way of advertising lacking functionality, which is effectively the only way that Linux can be usefully interpreted today. We don't want machines to automatically repost their video if they detect they're running Linux. It makes it harder to implement proper kernel-level graphics resume code. We don't want them to suddenly alter their keyboard behaviour, because that probably makes it harder to support older machines that don't have these workarounds.

Message to vendors: If we're not behaving in the same way as Windows does, let us know. We'll fix it. This has the benefit of fixing not only your latest and greatest platform, but also all the older ones that expected the same behaviour. Please don't try to work around our bugs in your BIOS - it just means that we need to special case you forever, and in the long run your hardware won't work as well as it would if we just fixed things properly.

Thu, 17 Apr 2008 23:01:33 GMT

Another update of my AHCI force quirking patch, somewhat cleaned up to let the existing kernel code do more of the work. The only functional change in this version is that some of the chipset IDs are disabled. The Intel specs state that plain (non-RAID supporting) desktop chipsets don't support AHCI. If you find that enabling one of the disabled IDs works for you, let me know along with the output of lspci -vxn -s 1f.2 . Patch is here. Success and failure reports welcome.

Note: I've had one report of SCSI errors associated with a previous version of the patch. I'm not quite sure what's going on there, but if you're paranoid about data corruption then you probably shouldn't play with this right now.

Thu, 17 Apr 2008 20:06:04 GMT

This week I'm in Mountain View for the X Developers' Conference, where I gave a presentation on things graphics drivers have to care about in order to make suspend/resume work reliably. Various people suggested that I write up an explanation of the current situation, along with some best practices for manufacturers.

One of the major differences between the ACPI specification and the older APM specification is that saving and restoring hardware state is generally left up to the operating system, with the firmware playing a much more passive role. Linux is now able to handle this state restoration for the majority of hardware, but we still have issues with graphics. Modern graphics hardware can be hugely complicated, which to a large extent we've been able to ignore because the platform will initialise it on boot. Many X drivers know how to switch a card from text mode to graphics mode (and vice-versa), but that's not adequate.

What can make this situation even more awkward is that the ACPI specification makes no guarantees about what state the hardware comes up in. It may still be in PCI D3. It may be powered up, but the registers may all be zeroed. It's even valid for the hardware to come up in text mode. A driver has to be able to deal with all of these situations.

So far, we've mostly tried to deal with this situation by running chunks of the video BIOS with applications like vbetool. This is hacky and often works badly - in some cases, it won't work at all (nvidia rewrite the entry point to their video BIOS after boot, in order to prevent situations where someone attempts to POST the card and it tries to jump to bits of the system BIOS that no longer exist). The only long-term option is for the kernel to handle the graphics suspend/resume. There's several levels at which this can be supported:

Able to restore text mode. This is basically adequate right now, since the kernel enforces a virtual terminal switch around suspend/resume.
Able to restore arbitrary video mode. In the kernel modesetting world, we want to be able to go straight into the mode that we're running X in, in order to reduce screen flicker. This would probably still be surrounded with a VT switch out of and into X.
Able to jump straight into X. Right now, on x86 the process freezer will prevent X from running until after all of the devices have been resumed. As we move to a model where we remove the freezer and expect drivers to be able to block userspace tasks, we hit a pretty obvious problem with X - right now it hits the graphics hardware directly, rather than going via the kernel. With nothing to block it, it'll hit the hardware while it's still in an undefined state and then become very unhappy. This can't really be fixed until X does all its hardware access through the kernel. For now, we can inhibit X by leaving the VT switching in place.

Since 2.6.25, i915 and later Intel hardware can manage basic mode reprogramming without requiring any external assistance. The radeon kernel modesetting code is also heading in this direction, and we ought to be able to manage something there before too long. The nouveau developers are heading towards the stage of being able to do native mode programming, so there's some hope of progress there as well.

It's not all plain sailing, though. Vendors can wire up hardware in different ways. AMD and Nvidia hardware provides scripts in the ROM that, in theory, abstract this away. The downside to this is that we'll have to put the interpreters for these scripts in kernel space, though this is probably needed for kernel modesetting work anyway. Even then, it's possible that we'll need workarounds for specific pieces of hardware that don't quite behave as we expect them to.

As far as making graphics work over suspend/resume, we have a pretty good idea where we are now (failing on anything other than modern Intel hardware), where we need to be in the future (triumph, huge success, cake) and how to get there (?). However, hardware manufacturers can still help.

Chipset vendors:

Tell us how to reinitialise your hardware. If that involves parsing BIOS tables, then please let us know how to do that. Expecting us to jump into your ROM and execute x86 code is ok if that's genuinely the only way to do it, but for any modern hardware that's clearly not the case.

System vendors:

Try not to alter your system behaviour too wildly. Requiring magic register writes in order to light up the VGA output does not classify as value add. Please don't have your firmware program text mode directly - we're trying to get away from that. And do not attempt to detect that you're running on Linux and alter your system behaviour. If it's possible for you to tell that you're not running on Windows, that's a bug in Linux. If you rely on that bug, you will break. I'm not joking here in the slightest. The closest thing to a "standard" interface between an OS and the hardware is whatever Windows does, and we're basically aiming for bug-for-bug compatibility there.

Sun, 13 Apr 2008 22:24:35 GMT

Dear RSA,

Turing Lives? Leaving aside the fact that your biography entirely fails to mention the manner of his death (security through prejudice? Wait, hang on...), this bit really seems excessive:

There’s no telling what Turing would do if he were around today, but one thing is certain, he would attend RSA Conference to gather and share new ideas and inspiration

Speaking for the dead in order to further commercial concerns? The dead baby Jesus weeps bitter tears, so buy my t-shirts.

Sun, 06 Apr 2008 15:15:34 GMT

Now that I've got a little more time on my hands, I've updated and done some bugfixing on my patch to quirk ICH devices over from PIIX-compatibility mode to AHCI mode. It turns out that ICH8 is a little different to ICH7, and needs an extra bit to be set. Without that being done, the AHCI BAR would still be programmed as i/o ports. Interpreting this as mmio space let to unsurprising crashes. With a bit of luck, this should also fix the "My CD drive is no longer there" issue - you'll still need to load ata_piix in order to access it, but make sure you do it after ahci has bound to the sata controller.

Patch against 2.6.24 is here - let me know if it works for you.

(Context: AHCI provides support for various features that the PIIX compatible mode doesn't, including link-level power saving. This is potentially beneficial for mobile users)

Fri, 28 Mar 2008 15:39:17 GMT

Ext JS is some sort of Javascript framework stuff. I know nothing whatsoever about Javascript, but what interested me was the slightly odd license. If you're a non-profit you can have it under the LGPL 3.0, but if you want to use it in a library then you have to buy a commercial license for them. This seems at odds with my understanding of the LGPL, but anyway. I'm a non-profit, so I've downloaded it under the LGPL. Under my LGPL rights, I've put it up for download here. If you want to use it in a library, feel free to do so as long as you abide by version 3.0 of the LGPL.

Thanks to Decklin for pointing this out.

Sun, 23 Mar 2008 03:07:34 GMT

Because you all love me and deeply want to know what on Earth I'm doing with my life/want to hire me, I'll put you out of your misery and let you know that I've just accepted an offer from Red Hat to ~~save the universe~~ work on kernel and userspace power management. With luck, it'll go some way to making up for the ridiculous amount of flying I'm still due to do this year.

Fri, 21 Mar 2008 16:01:50 GMT

I'm moving to London in a bit over a week, which means disposing of some quantity of junk, moving some more to London and hiding the rest (anyone got any recommendations for storage? I don't need regular access, but life would be immeasurably easier if they can pick stuff up and take it away). It also means the end of almost 10 years of living in Cambridge, and as a consequence there will be a party in the usual location on Friday the 28th. And possibly also on Saturday the 29th, depending on how much alcohol there still is lying around.

Also, if anyone in the Cambridge area wants some junk, the current list is here. I'll update stuff here as necessary.

Fri, 14 Mar 2008 21:17:48 GMT

Wednesday:

Today:

Hurrah for the open source development model!

(One of these taken by someone who can take pictures, and one taken by me)

Fri, 14 Mar 2008 01:32:54 GMT

Airports visited in the past week: 4 (rising to 6 in 12 hours or so)
Terminals visited in Heathrow: 2
Terminals enjoyed in Heathrow: 0
Vending machines in groundside of Heathrow terminal 2: 2, hidden near the men's toilets
Temperature of "ice cold" Coca Cola from vending machine: 5°C
Currencies currently carried: 4
Passports currently carried: 2
Fuses blown in airports: 1
Belonging to me: 0
Gross vm86-related hacks perpetrated: 1
Number of x86 instructions to emulate in order to achieve the above: 21
Number actually emulated as yet: 0

Those of you who haven't been too busy not paying attention will already know my whereabouts on the 13th of October and why my alibi is weak but that's another story for another time, but also that I'm in Recife from tomorrow afternoon until some time on Sunday and Porto de Galinhas from then until Wednesday in order to present at Bossa to talk about Ubuntu Mobile and the challenges involved in turning a Linux desktop distribution into something suitable for devices that are less large than your face. Sadly, logistical errors on my part mean I won't have any demo hardware with me, but there's always some potential for other synergy. Please don't beat me to death. Ow. Not the face. Please, not the face.

Sat, 08 Mar 2008 02:16:50 GMT

Dear Mountain View,

Why is it so indescribably awkward to get from north of 101 to downtown on foot?

Fucking sort it out,

Matthew

Wed, 05 Mar 2008 11:53:57 GMT

It seems fashionable for people to finish their doctorates at their moment, and on Monday I (almost) joined the herd. The outcome of my defence was that they'd like a couple of extra experiments done, so it's back to the lab for a fortnight, new credit cards for everyone[1] and cab it to the Gold Club[2].

Tomorrow sees me continuing my one man campaign to destroy the planet's ecosystem by heading to the bay area[3] for a total of just under 48 hours. I then continue to France for a few days of holiday, before reversing and hitting up Recife for Bossa 08. Alarmingly this still all involves less time on planes than LCA did, which makes me conclude that Australia is in a silly location and we should ship it somewhere more convenient, like just off the west coast of Ireland.

[1] Possibly lie
[2] Definite lie
[3] Mostly the south bay. Because I hate life.

Boston

Mon, 18 Feb 2008 04:41:25 GMT

Back in the US, crashing with kernelslacker and marvelling at the fact that Snoop Dogg has a reality TV show on bringing up kids. It also seems that the cosmetics industry has solved the cancer problem, based on the number of adverts that show magic moisturiser molecules appearing to repair DNA.

Leaving on Tuesday, some potential for booze on Monday. I'll be at FOSDEM from Friday, and ought to be at Bossa next month. April sees LRL US and power management or laptops or some sort of hangover-inspired song and dance interpretation of the driver model.

(Edited: cancer problem, not cancer industry. Sometimes I wonder about myself)