[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mcrei7hnfs2.fsf@google.com>
Date: Wed, 09 Feb 2011 11:56:13 -0800
From: Ian Lance Taylor <iant@...gle.com>
To: "Ted Ts'o" <tytso@....edu>
Cc: Martin Capitanio <m@...itanio.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
golang-dev <golang-dev@...glegroups.com>,
Russ Cox <rsc@...ang.org>, Alan Cox <alan@...rguk.ukuu.org.uk>,
Albert Strasheim <fullung@...il.com>
Subject: Re: [golang-dev] Re: mmap, the language go, problems with the linux kernel
"Ted Ts'o" <tytso@....edu> writes:
> Linux has interpreted it to mean "virtual address space", and in fact
> it's documented as such in the its version of the getrlimit man page.
> I'd have to agree with Linus that it's probably way too late to change
> what it means (or what Linux thinks it means, anyway).
I don't think anybody seriously expects Linux to change the meaning of
ulimit -v at this point. Obviously Go is going to do something
different here.
However, I think it's still worth pointing out that while ulimit -v no
doubt has specialized applications, it does not do exactly what I think
most people want. I think most people want some way to say "do not let
this program cause my machine to start thrashing." That's what I use
ulimit -v for; if I don't, a program which accidentally allocates memory
in an endless loop starts thrashing. But I don't actually care how much
virtual memory the program is using; what I care about is limiting the
amount of physical memory it is using, so that it doesn't take over my
machine.
I think that would be a useful feature to implement regardless of how we
feel about ulimit -v and Go. I think we can reasonably expect more and
more programs to try to advantage of large virtual address spaces. Lets
have a way to use them while still having a way to keep them from
thrashing.
Ian
--
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