The USS Quad Damage

Linux for Gamers 3: Processes and Services

As gamers, it is incumbent upon us to know exactly what's running on our systems and why, so that we may run games at their peak efficiency.

Alsa is very configurable, but also very complicated

In the previous article, I talked about the linux distribution and what that means (see also the first article about the filesystem if you haven’t yet). In this article, I talk about the processes and services which are running on your Linux box, why they’re there and what that means for games.

When Linux starts, the kernel will unpack a mini filesystem into RAM called the initrd image. This is mostly so that if you have an... interesting setup on your PC it will still work. The kernel will load up all your drivers and initialise your hardware. It will then hand over control to an “init” process. In the past this used to be very close to an autoexec.bat style thing, where init would launch all the services on your PC and finally the GUI.

Nowadays much fancier systems are used, named Upstart and SystemD. Upstart was invented by the Ubuntu guys, and is used on most of the Debian based distros and SystemD is starting to be used everywhere else. Upstart is older and more stable, but SystemD aims to be fancier (maybe too fancy). Overall it doesn’t matter much which one you use. Both systems try and start services only when they’re required, and in order (so a service that depends on another service will start in the right order). This broadly means your PC should start up quickly. There are GUIs to start, stop, and auto-start services, similar to in the windows management console.

Once your computer has started up and you’ve logged into whatever GUI you’re using, you can use the system monitor application to look at which processes are running. Here are some important processes:

  • DBus — DBus is like twitter for your PC, except it is used by services, drivers, and other subsystems. A subsystem can effectively “listen” to other subsystems for particular messages. When you insert a USB device, for example, a DBus message is created by the driver and your GUI will realise that it needs to do something (e.g. refresh your screen or give you a menu asking what to do). A huge amount of communication between applications as well as between the kernel and user space happens via dbus.
  • GVFS — This stands for the GNU Virtual File System1. This allows programs to ask for a URI over the internet, on your filesystem, via bluetooth, and so on, and have the ability to get at that file.
  • sshd — The secure shell daemon. Most services tend to end with “d”, meaning “daemon”. A lot of computers run the SSHD so you can log into them remotely. This can come in handy, so there’s no reason to remove it.
  • avahi — Avahi is the Linux name for Apple’s Bonjour aka Zeroconf. It allows you to look at things on your own local network and access them. This is often useful.
  • tracker / beagle — These services index your personal files. This usually means quick searching. These are often not required and could take up a fair bit of CPU + hard disk. However, once they’ve finished indexing they use hardly any resources, so there’s no reason to not leave them around. FWIW tracker has been implemented in C, whereas beagle has been implemented in C#, so tracker is the more efficient indexer.
  • Pulseaudio — This handles all user-level audio on your system. This means handling all the sound cards you may have, mixing audio, etc. However, this is not good for games, as it introduces a fair bit of latency to audio. Luckily, most games appear to use the underlying “alsa” sound drivers to actually play audio.
  • Xorg — This handles all video on your system, as well as a consistent way of handling device input. However, it was originally architected for use over networks, and it supports a lot of legacy applications, so it is considered bloated. It should be replaced any day by Wayland.
  • Wayland — This handles all video on your system, as well as device input. This will, in short, fling your keystrokes straight at the application you’re running, and then fling your display data straight at the video card at high velocity. However, it does not support “legacy applications”, which is pretty much everything at this point in time.

Some of these services require a bit more in depth discussion regarding the drivers. For PulseAudio, this is the sound driver. In the olden days this used to be the OSS (or open sound server) driver. OSS is very simple, but also suffers from a lack of flexibility, especially when the sound card wasn’t very good. However, now Linux uses the Advanced Linux Sound Architecture, or ALSA. Alsa is very configurable, but also very complicated. Sound cards are connected up to virtual sound cards or mixers which you can send audio to. Fortunately, Pulseaudio handles all those problems for you. Unfortunately, Pulseaudio also appears to add an unacceptable audio latency to games. Hopefully the situation will improve in the near future.

Video is a little more interesting. Linux, at least for the open source drivers, uses something called DRI, or the Direct Rendering Infrastructure, to lay out graphics drivers. There are two main parts to DRI. The first is DRM (Direct Rendering Manager, not the evil kind of DRM) which sits on the kernel side and basically provides “neat” raw access to the video card. Then there is a user-space “other half” to that DRM driver. They form a sort of “matched pair”, but luckily there are rarely cases where the interface changes between the user-space and the kernel, and this is managed by apt-get anyhow.

In addition to the user-space driver, there are also the OpenGL2 libraries, which require some additional tweaks depending on the exact video card and driver set you’re using. All open source drivers use one OpenGL library, nvidia’s proprietary driver uses another, and the ATI proprietary driver uses another again.

The user space “driver” half is actually a driver for the Xorg server (or, in the near future, the Wayland server). Applications talk the standard Xorg language, or OpenGL language, and control the video card via the driver. Wayland basically gets rid of a little bit of the indirection, but that’s something that only affects something called “compositing”. Compositing is like Windows' Desktop Window Manager (dwm), which basically adds “shiny” on top of Windows 7. It can be disabled in Windows, and it can be disabled in Linux (which we’ll talk about next time).

Incidentally, as a rule of thumb, the open source drivers are the nicest but the slowest, the open source ATI driver is better than the open source NVidia driver, the NVidia proprietary driver is the fastest but slightly rough, the ATI proprietary driver is rough and not that great. I’d recommend an NVidia card for Linux at the moment, and the closed source drivers are the best. If you have AMD the closed source is still the best but it isn’t as good as Windows, and it isn’t excellent stability. Having said that, AMD’s open source drivers are better than NVidia’s, so if you’re drinking the open source kool aid, then AMD’s cards are the go.

This should give you a better idea of what’s running on your PC in Linux, and how all the running processes fit together and talk to the Kernel (especially the Video, Audio, and Input, which are very important for gaming. Next time, we’ll talk about the Desktop Manager, which is the GUI that you interact with.

1 I think. There’s been a convention of many Gnome subsystems (we’ll talk about Gnome at a later date) which used to be heavily intertwined with the Gnome libraries to have the name GnomeXXX, so GVFS used to be called “GnomeVFS”. Eventually these interdependencies were removed and the VFS (or other subsystem) became more generally useful. The new name became simply “gvfs”.

2 I’m hoping most of you will know this already, but OpenGL is the “open” version of DirectX (graphics), and roughly comparable features-wise.