Requesting 'real' memory

Obviously we're totally talking past each other, but I'll try one more time...

>Though you start out saying overallocation has nothing to do with swap, your second sentence
shows that it is strongly related to swap, saying that swap space is half the equation in
determining how much memory is available to allocate.

Well, sure, swap is, by any measure, an important part of a VM system, but that doesn't mean
it's "strongly related" to any other particular part of a VM system.  My point is that from
the point of view of overallocation, the difference between swap and physical RAM is just
irrelevant.

> But what overallocation are you talking about? You describe it like some well-defined Linux
function. Are you talking about something that Linux implements?

Yes.  I'm talking about "overallocation" or "overcommit", which in this context is a technical
term with a precise meaning.  When people are talking about it in this thread, they are
referring to a particular policy implemented by the Linux kernel and enabled by default.
Evidentally you haven't encountered this particular design before, which is why I described it
in my previous comment...

>AFAIK, Linux does not implement a per-process overallocation mode, and we were talking about
what should be.

No, AFAIK it doesn't, but it does support a global overallocation/no-overallocation switch,
and it's obvious what it would mean to take that switch and make it process-granular.  Maybe
there's yet another policy that Linux should implement, but if you want to talk about that
then trying to redefine an existing term to do so will just confuse people.

>And the way to do that is to allocate swap space to the process at the moment you allocate
the virtual addresses to it.

Huh, so is this how traditional Unix works?  Is this tight coupling between memory allocation
policy and swap management policy the original source of that old advice to make your swap
space = 2xRAM?  I've long wondered where that "rule" came from.

I guess I've heard before that in traditional Unix all RAM pages are backed on disk somewhere,
either via the filesystem or via swap, but I hadn't thought through the consequences before.

I'm guessing this is the original source of confusion.  Linux doesn't work like that at all;
I'm not sure there's any modern OS that does.  In a system where RAM is always swap-backed,
having 1G RAM and 2G of swap means that all processes together can use 2G total; in Linux,
they can use 3G total, because if something is in RAM it doesn't need to be in swap, and
vice-versa.  (What happens in your scheme if someone is running without swap?  I bet there are
people in this thread who both disable overallocation and run without swap (hi Zooko!).)

"Allocated memory" in my comment really just means "anonymous transient data that the kernel
has committed to storing on the behalf of processes".  It can arrange for it to be stored in
RAM, or in swap, or whatever.  There is no such thing as "allocated swap" or "allocated RAM"
in Linux.  (Except via mlockall(), I guess, if you want to call it that, but I don't think
calling it that is conceptually useful -- it's more of a way to pin some "allocated memory" 

Does that make my previous comment make more sense?