12

I just executed dot (a program for drawing directed graphs) with an input file that was so big that it couldn't be rendered in a reasonable amount of time.

My whole system froze. I could barely make it to a text console with Ctrl+Alt+F1 to kill dot, but it took several minutes.

Why does the system allow something like this? Why does it give a non-critical program such as dot 99% of the system and use the remaining 1% for staying responsive?

Improve this question
1

1 Answer 1

Reset to default
15

That's the way GNU/Linux and other multitasking systems work, they share the processor among the running processes, dot won't have 99%, but 100% during 99% of the time. Each process dominates the processor for a certain period of time.

This is handled by schedulers (linux has several schedulers, some just employ the usual strategy, some try to give more time to user interfaces, and so on).

Now, in your case, the problem was — probably — that dot wasn't taking a lot of processor time, but lots of memory. And when a program uses too much memory, there is thrashing, which is exactly a process that makes the system freeze, not because dot is doing a lot, but because the kernel has to move memory pages back and forth between the disk (swap partition) and the system memory.

Even if dot was just taking 99% of CPU time, chances are that changing to a text terminal would be almost immediate, what happens is that the kernel has to move dot stuff out of memory so it can put X back in memory so that X can see the keys you just hit and move to the text terminal, then the kernel has to move X out of memory for dot which is still running, and then also move dot out to move the text terminal processes (maybe just login?) back in memory. (If this looks messy, it's not just because the example is messy — the reality is this messy.)

An example is if you log in the text terminal, you may be able to just hit keys, hit backspace, and it will happily happen real-time, but if you do something as simple as running a small tool like ps, it will "freeze" for a while because it has to free memory to load ps (and it also has to wait in the disk I/O queue, which is being heavily used to move data to and from memory, until it is able to request ps from the filesystem).

Improve this answer
3
  • Hm, so the way to a better user experience would be to specify certain programs as "sticky" and thus prevent those from being swapped out.
    – Christoph Wurm
    Commented May 23, 2012 at 13:40
  • Stickiness hasn't worked like that since the 70s and the original semantics of the ‘sticky’ bit. You can, however, lock (parts of) programs into memory so they can't be swapped out. Main memory is an expensive luxury though, so this can't be done for everything.
    – Alexios
    Commented May 23, 2012 at 15:17
  • @njsg, thanks for the good explanation. A follow-up question: Is there no way to prevent thrashing? I understand that swapping makes memory usage more effective on the whole, but there should be limits. IMHO a process as essential as X should never be moved out of memory. Is there a way to configure a unix-like system such that essential processes are protected from being moved out? On a server its a different thing, but on a desktop I'd rather have a memory-hungry process to crash than to have my desktop stop talking to me.
    – A. Donda
    Commented Sep 30, 2013 at 16:29

You must log in to answer this question.

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