Re: mmap, the language go, problems with the linux kernel

[Russ Cox <rsc@golang.org>]

I don't think there is that much more to say but thanks for
assembling the To: line.

Go is still very much an experimental project.  It is fine
in our opinion to try things and see how they work.
We're happy to revisit design decisions if some of the
possible negatives that have been identified come to pass.

I agree with what Linus posted about it being of only very
long-term utility to change the kernel interface, and probably
not worth doing at all.  I think it's unfortunate (at least for the
people who think ulimit -v is useful for keeping your machine
from swapping) that mmap with PROT_NONE counts against
ulimit -v, but it is what it is.

In Alan's scenario about vm_overcommit, since that is a
Linux-specific feature and presumably more malleable, I would
hope that the "commit" charge doesn't happen until you do
mmap with prot != PROT_NONE.  As I said in some of the
quoted text, there are various sandboxes like Native Client
or VX32 that assume they can use mmap as a way to set up
restricted sub-address spaces at low cost, and I don't see
the benefit to committing the physical memory before the
addresses are mapped accessible.

Russ