Rik van Riel on Kernels, VMs, and Linux

Andrea Scrimieri writes " An Interesting interview with Rik van Riel, the kernel developer, in which he talks about the Linux's VM, particurarly about his own implementation (which was recently adopted in Alan Cox's tree). With some controversy towards Linus Torvalds. "

Comments

Re:Minor nit...

[Rik van Riel]

Both Alan's and Michael's kernels are including my -rmap VM now.

This is quite interesting since I haven't begun tuning -rmap for speed yet ;)

Re:Multi-proc 'big iron'..

[Rik van Riel]

Indeed, it is important to optimise the VM to work right on such large machines. I guess what I wanted to say is that the VM isn't just optimised for high-end machines, but also for machines on the low end.

To be honest though, optimising for machines of different sizes really is a no-brainer compared to having to make the VM work with really diverse workloads ;)

On developer spats and high drama

[ajs]

Open Source's biggest PR dilema is this sort of argument.

Make no mistake, every company has developers that do this. There's two differences in the Open Source world: 1) you can't just fire an Open Source developer who won't "play ball" with management's edict 2) it's usually public.

These are actually both really good things. The fact that you can't silence someone leads to repeated analysis of a problem. OSS' biggest benefit is that it brings massive peer review to bare not just on the code, but on the process.

The fact that it's public feeds into that, and is equally good.

The problem is PR. The Linux kernel is starting to look like anarchy to non-developers. I suggest that the process works, so we should all take a deep breath and leave it be. However, we all need to take the front lines on PR. Spin is all-important. This is not a "spat" or a "fight", this is "parallel development" and "peer review". The joy of this kind of spin is that, unlike most spin, it's TRUE! This guy is pissed at Linus. Linus has dumped his code. Yet, the two of them keep working hard to meet their customers' demands and producing what they feel is the best possible product.

Please, don't foster the idea that we're a bunch of anarchists producing code that's any less functional than the rest of industry, because quite the opposite is true.

Re:Patch bot is the answer?

[Rik van Riel]

The problem is simple: maintainers of any parts of the kernel get flooded by email, maintainers of the whole kernel (Linus, Alan, Marcelo) get flooded even worse.

You really cannot expect these people to read all their email all the time, so patches and bugfixes get lost and may need to be resent various times before they get noticed.

Add to that the fact that many of the people writing these patches are also extremely busy and may not get around to resending the patch all the time (I know I don't).

The solution here would be to have the patch re-sent automatically as long as it still works ok with the latest kernel version ... this can all be checked automatically.

OOM Killer must die

[Salamander]

Rik is an extremely bright (and likeable) guy, but his adherence to the OOM killer concept is disappointing. I've seen a lot of dumb ideas gain currency in the computing community or some part of it; OOM killer is the dumbest. If your process was allowed to exist in the first place, it should not be killed by the VM system. The worst that should happen is that it gets suspended with all of its pages taken away. If that doesn't free up any memory then neither would killing it (modulo some metadata - read on). If there are other processes waiting for the one that's suspended, then eventually they'll go to sleep, their pages will be released, and the suspended process will wake up - which won't happen if you killed it. There are only two differences between the two approaches:

• Suspension does not take irrevocable action; the suspended process can still be restarted.
• Suspension bears the cost of retaining the metadata for the suspended process so it can be restarted.

The usual whine from OOM-killer advocates is that you can still get into a situation where all of that retained metadata clogs up the system and essential system functions can't allocate pages. However, that's preventable too. All you need to do is preallocate a special pool of memory that's only available for use by those essential system processes - either individually or collectively. The size of that pool and the exact details of how it gets allocated (e.g. which processes are considered essential) could be treated as site-specific tuning parameters. The same idea can then be further generalized to allow definition of multiple private pools, creating a semi-hard barrier between different sets of tasks running on the system (if you want one; the default pool is still there otherwise). This actually fits in very nicely with other things like processor affinity and NUMA-friendly VM, which I know because I once worked on a kernel that had all of these features.

In short, there's no need for the OOM killer. Plenty of systems, many of which handle extreme VM load much better than Linux, have been implemented without such a crock. Rik contends that a lot of people make suggestions without actually understanding the problem, and he's right, but I also submit that sometimes he also rejects suggestions from people who do know what they're talking about. This row has been hoed before, and Rik's smart enough that he should know to avoid the NIH syndrome that afflicts so many of the other Linux kernel heavyweights.

Re:OOM Killer must die

[Salamander]

So we know before a process gets to execute exactly what its memory usage profile is?

Please don't construct strawmen. Oh wait, that's not just a strawman, it's also circularity. You're assuming that the OOM killer exists, then using that to "prove" that an alternative approach is impossible to implement. Well yeah, an alternative system that both does and does not incorporate the OOM-killer concept is impossible. Congratulations. Well done.

What I'm really saying is that the VM system should ensure that it has other means to deal with memory exhaustion. Disallowing overcommit altogether is one approach, and that has proven quite acceptable for many systems, but there are plenty of other approaches as well. I've briefly sketched out only one; look up the others yourself (the information is available in plenty of places including some OS textbooks).

"taken away"? Where do they go?

The phrase "suspended with all of their pages taken away" (which is what I said) includes the case where the pages have already been taken away. English 101.

As for where they go, the obvious answer is not the general swap area, because that's already full. However, that doesn't preclude the existence of a secondary (actually tertiary) swap area that exists only for this purpose. It could also be a percentage of the general swap area, which starts to look very much like the memory-pressure code in the very highly regarded FreeBSD VM, or Solaris, etc. The point is that there's a middle ground between "no overcommit at all" and "if you allow overcommit we might shoot you in the head just because we feel like it".

Color me skeptical.

Skepticism is one thing; strawmen and circularity are another. I'm skeptical about the need for an OOM killer.