Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

First question on overflow =)... +100 bounty. Couldn't think of something I really cared about until now:

I'm really fed up with the state of Linux desktop responsiveness, e.g. -- in situations with low free-RAM, or situations with high disk throughput, the system slows to a crawl; this is absolutely terrible for applications which require decent performace. Additionally, the UI is completely unresponsive. Compare this for example with OS X, where if an application is hogging resources, one can always option-click to Force Quit it, whereas in Linux I cannot even alt-tab or switch desktop, or even ctrl-alt-f1 to get a terminal -- well I can, it just takes about 1-2 minutes per operation.

I use gkrellm so I can see the situation as it unfolds. Typically the memory utilization becomes pretty high, or the disk throughput jumps dramatically.

It's not bad hardware, with a 2.6GHz quad-core and 4GB of 800MHz DDR2 RAM (would have had 6GB, but due to a hardware incompatibility couldn't mix-and-match with old set). This problem may go away when I inevitable get more RAM, but I don't feel that's the heart of the problem. I even have two swap partitions on different disks.

I feel the problem is threefold:

  • runaway programs that hog up massive amounts of memory -- the law must be laid down for these programs, with limits on their
    • (e.g. tabs on Chrome, each of which is 20-50MB, some of which can use hundreds of MB)
    • (e.g. other programs like update-db and indexers which I've had to disable and remove from cron because they were slowing the system to a crawl whenever they ran, etc.)
  • something terrible going in the kernel or bus contention of some sort, such that high-disk-throughput situations slow the entire system to a crawl (perhaps by paging out important programs)
  • the kernel is not prioritizing UI or important programs in terms of resources, such as memory, paging, even processor utilization

Upvotes go to:

I am thus looking for a solution where all such programs go away. In particular, I am looking for a solution such that the processes will slow down proportionally, while the system and other programs remains entirely unaffected and responsive long enough to manually kill something. Also the window manager process (and anything else that might affect UI responsiveness) should be responsive under all circumstances.

In particular I am intrigued by /etc/security/limits.conf (man limits.conf), but am worried this only gives per-user control, and the commented examples in the file seem rather opaque in terms of description or where to begin. I'm hoping that a limits.conf works, but would not be surprised if it didn't even work, or if it was not an appropriate solution for my problem, or as granular as I'm trying to achieve. A per-process-name limits.conf would be ideal, assuming again that limits.conf works. I'd be happy to try out a limits.conf that people provide, to test if it works, though I'm open to all solutions at this point.

It might also be useful to have any insights on how OS X manages to keep up such good UI responsiveness.

I have already tweaked my /tmp and cache folders to be on tmpfs, and in general disk utilization is near-zero.

Vaguely-related topics:

  • memory overcommit

Answers I do not think will work:

  • swapoff (this still lets memory hog programs get away with murder, and the system permanently freezing if memory is really bad -- upvotes to anyone who can suggest a tweak that invoked the OOM-killer earlier before swapping and targets specific programs)
  • echo ?? > /sys/.../swappiness (no discernable effect)
  • nice (has never worked)
  • ionice (never noticed a difference)
  • selinux (program incompatibility seems to be a nightmare)
  • realtime linux, i.e. can interrupt kernel (don't want to deal with compiling and updating custom kernel; might be okay if it has migrated into repositories)
  • *
share|improve this question

This question has an open bounty worth +100 reputation from Vlad Frolov ending in 4 days.

The question is widely applicable to a large audience. A detailed canonical answer is required to address all the concerns.

This is still an issue 4 years later. My guess is that the root cause is somewhere around freeing and reloading libraries when a system is going out of RAM, which makes the whole system unresponsive.

hmm, I seem unable to place a bounty; I guess the link doesn't show up for 48hr?... well I'll be posting the bounty with all reputation I've acquired then –  user76871 May 15 '11 at 15:41
+1, this is the single biggest issue I have with the Linux desktop on a day-to-day basis. I have occasional freezes, perhaps once every couple weeks, but those are not often enough to get particularly annoying. However, it only seems to be an issue with applications that have, as you said, heavy IO utilization: Applications that have heavy CPU utilization have little no no effect on general system performance. Didn't know about ionice, it seems that it would be the correct solution to this problem if it were to work properly. –  crazy2be May 16 '11 at 2:24
3 years later and this is still an issue on Linux. @crazy2be or user76871, I don't suppose you have found a solution in the meantime? –  Glutanimate May 18 '14 at 4:24
@Glutanimate: yes, 32GB of physical RAM and no less (well, maybe 16GB... but that's pushing it), also maaaaaybe large amounts of video RAM. This doesn't fix unresponsiveness due to high CPU or interrupts or whatnot, but it does prevent unresponsiveness in low-memory situations. –  user76871 Jun 12 '14 at 2:23

3 Answers 3

Sounds like your system goes into heavy swapping. Using vmstat 1 may reveal some details - just let it run in a terminal window and switch to it when the slowdown kicks in.

Rather than putting /tmp and "cache" into tmpfs, I would use a normal disk filesystem mounted with the noatime option. Often used data will stay in the caches anyway, and older data can be written to disk to free some RAM for applications. If /tmp and/or cache grows bigger, this might help a lot.

share|improve this answer
+1 for mentioning noatime. –  LawrenceC May 15 '11 at 18:49
Thank you for mentioning noatime, unfortunately I used to use that mount option, and I don't think it helped much to ensure responsiveness (though it helps a ton to ensure the disk isn't overworked); just to be sure I've re-enabled noatime on my current setup. Having a non-tmpfs with noatime seems a bit strange though, since I'd still imagine massive writes must happen. –  user76871 May 16 '11 at 0:58
+1, tried vmstat 1 -- extremely useful in clinching diagnosis that swapping is, in fact, a large part of the issue main issue –  user76871 May 25 '11 at 18:24
Ouch. Never seen a linux system that needed such heavy swapping. Have you checked with df -m how much memory is used up in tmpfs filesystems? Something is eating your RAM relatively fast. –  Turbo J May 26 '11 at 5:25
thanks for the suggestion and teaching me about the -m option. Unfortunately df -h -m seems to indicate a mere 100MB of my memory is in tmpfs, so I doubt it is related any if at all to using memory for tmpfs and caches. This also doesn't seem that uncommon; I have had it happen on multiple distributions when their RAM is pushed to near the limit. –  user76871 May 27 '11 at 3:07

Putting all your temporary and cache files on a tmpfs is lowering the amount of free RAM you have, so you might be causing the system to go to swap sooner than it would need to without this.

It sounds like you have some applications that are relying on some sort of kernel facility or driver that is getting overloaded. You don't go into too much detail about what types of applications other than you are using browsers and indexers, and that you've disabled the indexers.

You might try switching to a desktop environment or window manager that consumes less resources, such as LXDE or IceWM. At work I use a Linux system with LXDE installed and ROX-Filer for a very minimal desktop environment. The purpose of this Linux system is to run VMWare Player so that I can run Windows XP and Windows 7 simultaneously. It's similar hardware specs to what you say and I don't have too many responsiveness issues under this heavy load I'm putting the hardware through. I don't have any responsiveness issues with Linux itself (it's usually the VMs that sometimes make me wait a second, and sharing 1 disk between 2 VMs + 1 OS this is expected) and have always been able to suspend or shutdown the VMs whenever I want to. This includes having Firefox running on Linux often in the background.

So to me it points to some issue with specific applications you are running.

Is DMA enabled for your disk drives? (use hdparm) If you are using full-disk encryption, that requires all disk traffic to go through the CPU which negates much of the benefit of DMA. The effect of that would be that high disk traffic causes CPU to spike which would then slow the entire system down. (EDIT: to clarify, having DMA disabled OR using dm-crypt will cause high CPU during high disk traffic)

share|improve this answer
The point of the question is not that the WM is bloated and causing the system to become slow (it is likely perfectly responsive under normal usage), but that the kernel is not properly prioritizing applications when it runs out of memory and has to go into heavy swapping. I've had this issue on every desktop Linux i've ever used, and while using lighter programs or adding more ram might help, it doesn't address the root of the problem. –  crazy2be May 15 '11 at 20:27
In my previous post I said the following: "It sounds like you have some applications that are relying on some sort of kernel facility or driver that is getting overloaded." So maybe the bottleneck is in a specific kernel module. I'm not a kernel expert, but I'm sure that memory allocation from the kernel side, especially module side, is working differently than userland side. CPU utilization in kernel side is also likely handled differently (don't know if you can "nice" kernel processes). I can't comment further without knowing the specific applications involved. –  LawrenceC May 15 '11 at 21:50
Also if you are using FUSE NTFS that can cause slowness. –  LawrenceC May 15 '11 at 21:50
I am aware that a RAM-based filesystem such as tmpfs (obviously) causes RAM to run out quicker, and that a lightweight WM can slightly reduce symptoms of the underlying issue. I felt pressured to use tmpfs due to the poor responsiveness writing to disk can cause. Nevertheless thank you for your suggestion, especially the part about DMA, which I've added to the list of possibly-related topics. For the record, I believe DMA is enabled, and I am not using a cryptographic filesystem. –  user76871 May 16 '11 at 0:54

This is a common problem with Linux's scheduler. The system slows down to a crawl whenever IO heavy activities occur. There aren't really many things you could do to improve the situation unless you're into kernel hacking :)

Maybe these can help:

share|improve this answer
As I recall, those kernel patches are really only relevant if you are compiling a program or doing something else that is very CPU (and IO?) heavy in a terminal, whilst trying to interact with GUI applications. It does not help in the more common situation where one GUI application is doing some heavy work and you are trying to work with another GUI application, unfortunately. –  crazy2be May 16 '11 at 2:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.