Throttling CPU usage with Linux cgroups

There are a number of reasons you may want to throttle rather than limit a process's CPU usage on your system. One very good reason is to keep the CPU temperature down or to simply reduce the amount of energy a certain process uses.

Limiting versus throttling

The term "limit" is nearly always used where throttling is actually required. A good example of why the two are not interchangeable would be the current ISP industry:

Example 1: Sally signs up for super fast broadband (100 Mbps) but hasn't read the small print: she can only download 10 GB of data before her connection is terminated and she has to wait for the next month before she can continue to use her service. Sally's service is not throttled but it is limited.

Example 2: Tony signs up for a basic package (1 Mbps) as he doesn't need to use the Internet a great deal. However he had the good sense to use an unlimited package so that he doesn't hit any usage caps. His router syncs at 100 Mbps but he only receives a 1 Mbps service. The ISPs equipment is throttling his service, but not limiting it.

Example 3: Benedict has signed up for some deal without reading any of the details. He receives a 20 Mbps service and is happy with the speeds. Unfortunately for him after downloading 5 GB of data his download rate drops to 1 Mbps. He has limits on his service which has led to it being throttled.

There are many instances where you may wish to both limit and throttle CPU usage. The former is very easy and well documented, the latter not so much.

Xpra failing on localhost

If you know Xpra then you know you can access a "background" X session remotely. It's reasonable to assume that you may also want to access it locally from time to time.

On Ubuntu Precise I was finding that attempting to access the local session failed silently. I have been using:

$ xpra attach -z0 ssh:user@localhost:99

This produces no output. The server log isn't very forthcoming either:

New connection received
Handshake complete; enabling connection
encoding set to rgb24, client supports ['rgb24', 'jpeg', 'png'], server supports ['rgb24', 'jpeg', 'png']
Unhandled error while processing packet from peer
Traceback (most recent call last):
  File "/usr/lib/xpra/xpra/protocol.py", line 338, in _process_packet
    self._process_packet_cb(self, decoded)
  File "/usr/lib/xpra/xpra/server.py", line 1957, in process_packet
    self._packet_handlers[packet_type](self, proto, packet)
  File "/usr/lib/xpra/xpra/server.py", line 1371, in _process_hello
    f = open(mmap_file, "r+b")
IOError: [Errno 13] Permission denied: '/tmp/xpra.QGv7UA.mmap'
connection lost: empty marker in read queue
Connection lost

The clue is in the .mmap. The server needs to be started with the --no-mmap option.

From the man page:

       --no-mmap
              Disables memory mapped pixel data transfer.  By default it is normally  enabled  automatically
              if  the  server  and  the client reside on the same filesystem namespace.

All good!