All GNU/Linux distributions I tested so far have the problem that whenever the ram gets filled and the system begins swapping, the whole desktop and graphical user interface becomes unresponsive as hell to an extent that sometimes I have to wait about 5-10 seconds after having moved the physical mouse until the mouse pointer is actually moving.

This is kind of an annoying behaviour, especially on systems with low ram.

Is there any way to give some applications/jobs, like the desktop environment etc., a higher priority to stay in ram than other applications, so that the application actually hogging all the memory gets swapped before the desktop environment etc.?

EDIT: I'm talking of the case when the entire RAM is used so it will always start swapping if it isn't disabled (I don't want processes to be killed randomly). I had this problem not only in low ram environments, but as well with 8GiB of ram on my desktop machine, partly due to many VMs partly because of memory leakage. ZRAM isn't a solution either as it's only delaying the problem. The only solution I can think of for this problem is some userspace utility or kernel API that allows to prevent certain jobs to be swapped at all or at least make it very unlikely. Does anybody know another solution or knows anything about such a tool or API in existence or being planned?

2nd EDIT: ulatencyd doesn't seem to work with newer versions of systemd, according to https://aur.archlinux.org/packages/ulatencyd-git/ and https://wiki.archlinux.org/index.php/Ulatencyd . This may be because systemd took over full control of cgroups from a userspace perspective if I understand it correctly.

  • 3
    cgroups, if you have the memory cgroup enabled, and swap accounting enabled (cgroup_enable=memory swapaccount=1 on the kernel command line; note this has a minor performance cost). Example implementation: ulatencyd.
    – derobert
    Commented Sep 30, 2013 at 15:26
  • @derobert Great this seems like it's exactly what I was looking for. I'll start experimenting with this as soon as I have time.
    – FSMaxB
    Commented Sep 30, 2013 at 15:32
  • Great, ulatencyd even has an AUR package, guess I'm lucky being Archlinux user.
    – FSMaxB
    Commented Sep 30, 2013 at 15:46
  • There's even a wiki article wiki.archlinux.org/index.php/Ulatencyd
    – FSMaxB
    Commented Sep 30, 2013 at 15:51
  • If I could up vote this Q's more I would! Is there really no direct way to tell the GUI and few key programs to stay in RAM so it stays responsive? I mean, whats the worse case scenario of giving linux users this option? The computer crashes? WHO HASN'T DONE THAT BEFORE? :) I mean sometimes, I accidentally start too many VMs because I couldn't add (RAM numbers) correctly and then it takes FOREVER to bring things back under control. Telling the GUI and maybe terminal to stay in RAM would fix that right?! Please, someone answer this!
    – Damon
    Commented Oct 3, 2013 at 5:38

1 Answer 1


As far as I know this is not an issue specific to Linux, its the way that SWAP (or virtual memory) works. If the OS needs to look up data in the hard drive as opposed to the RAM, it will slow down. Nothing you can do about that, accessing the disk is way slower than accessing the RAM.

You won't be able to set the priority with which processes are swapped, that is determined by the kernel which will try to maximize efficiency, you won't be able to do it better. What you can do is set the CPU priority of a process and that might help. Your system is being lowed down because of the time it takes to read from/to SWAP, this means that the CPU will have to wait for the relevant data to be retrieved by the process requesting it before it can continue. If you set your DE to have a higher priority for CPU access, that should push its operations to the top and speed things up a little.

So, CPU priority is set with the nice and renice commands:

 Renice alters the scheduling priority of one or more running processes.
 The following who parameters are interpreted as process ID's, process
 group ID's, or user names.  Renice'ing a process group causes all pro‐
 cesses in the process group to have their scheduling priority altered.
 Renice'ing a user causes all processes owned by the user to have their
 scheduling priority altered.  By default, the processes to be affected
 are specified by their process ID's.

The priorities go from -20 (highest priority) to 20 (lowest priority). To change the priority of a running process, you could do:

renice -15 $PID

where $PID is the PID of the process whose priority you want to increase. You can use pgrep to find out which that is. For example:

renice -15 $(pgrep gnome-session)

The other option would be to set the system's 'swappiness' which determines when it will start swapping. A swappiness value of 1 means that it will only swap to avoid out of memory errors. Higher values means it will start swapping even when there still is physical memory available. You can set this to a relatively low value to make your system swap as little as possible. Add this line to /etc/sysctl.conf:


CAREFUL: That is not a good idea if you don't have a lot of RAM, swap is a Good Thing generally, you will need to play around with the values a bit to find the right balance for your system.

  • As you state this may be solved in kernel space, which means that it would very well be linux specific. Changing the swappiness won't change anything because when the entire RAM is used the system is swapping anyways. And afak the priority of a process won't change anything about it's memory management but only the behaviour of the cpu scheduler and cpu time isn't really helpful for speeding up disk access.
    – FSMaxB
    Commented Sep 30, 2013 at 15:04
  • @FSMaxB CPU priority might help since it will prioritize the DE, it won't help if the DE itself is swapping but it will if something else is which is holding up the CPU and therefore slowing down the machine.
    – terdon
    Commented Sep 30, 2013 at 15:11
  • When the DE is idle for some time, in my experience the DE always get's swapped when memory runs out.
    – FSMaxB
    Commented Sep 30, 2013 at 15:14
  • @FSMaxB yeah, that makes sense since DEs are memory hogs. Still, increasing its priority might help, at least the scheduler will not be holding it back.
    – terdon
    Commented Sep 30, 2013 at 15:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .