[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikO2GAAe8brJKzxVUzAkZ39dReU6TcVVE909_mB@mail.gmail.com>
Date: Wed, 9 Feb 2011 11:40:53 -0500
From: Russ Cox <rsc@...ang.org>
To: Martin Capitanio <m@...itanio.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
golang-dev <golang-dev@...glegroups.com>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Albert Strasheim <fullung@...il.com>
Subject: Re: mmap, the language go, problems with the linux kernel
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists