[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110208132657.1cf55782@lxorguk.ukuu.org.uk>
Date: Tue, 8 Feb 2011 13:26:57 +0000
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: martin capitanio <m@...itanio.org>
Cc: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: mmap, the language go, problems with the linux kernel
On Tue, 08 Feb 2011 13:37:58 +0100
martin capitanio <m@...itanio.org> wrote:
> There popped up a serious problem by implementing a fast memory
> management for the language go. Maybe some experienced kernel hacker
> could join the discussion and help to find the best linux solution for
> the "mmap fiasco" problem.
>
> https://groups.google.com/forum/#!msg/golang-dev/EpUlHQXWykg/LN2o9fV6R3wJ
>
> Thanks (in behave of all linux go users:),
I don't actually see a problem.
Linux implements virtual address space limits, and enforces them. The go
language stuff wants to allocate huge amounts of virtual space so you
need to tell the OS you want to allow it to do crazy stuff, which you can
do so. But virtual address space is not free - it has to be tracked and
if the application suddenely tries to fill all of it what will happen ?
You'll hit problems if the kernel is running with vm overcommit disabled
(as well configured servers do),
There are of course ways and means - you can provide your own mmap to
override the libc one for example and manage the address space yourself -
within limits by allocating addresses and doing the syscall giving an
address request.
You'll be ok I suspect on Linux on x86 but there are platforms with very
complicated aliasing rules where the OS tries very hard to map certain
things at certain addresses to avoid cache aliasing work and big slow
downs. There are good reasons why mmap works the way it does.
Alan
--
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