public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Ian Lance Taylor <iant@google.com>
Cc: Martin Capitanio <m@capitanio.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	golang-dev <golang-dev@googlegroups.com>,
	Russ Cox <rsc@golang.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Albert Strasheim <fullung@gmail.com>
Subject: Re: [golang-dev] Re: mmap, the language go, problems with the linux kernel
Date: Wed, 9 Feb 2011 15:11:08 -0500	[thread overview]
Message-ID: <20110209201108.GI9533@thunk.org> (raw)
In-Reply-To: <mcrei7hnfs2.fsf@google.com>

On Wed, Feb 09, 2011 at 11:56:13AM -0800, Ian Lance Taylor wrote:
> 
> 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.

Agreed, I don't think ulimit -v is particularly useful for much of
anything, especially in these days of 64-bit systems where we have
gobs and gobs of address space.

If the performance hit isn't that horrible, making Linux enforce
RLIMIT_RSS is probably the right answer for the "do not let this
program cause my machine to start thrashing".  But even that doesn't
help if you have some pesky program that fires up large number of
processes, like, say, Chrome.  :-)

So it's not a per-process limit that we really want; instead, what we
want to do is put a program like Chrome into its own container group,
and then use memcg to constrain how much memory all of the processes
in that container group is allowed to use.  And we can also use that
same abstraction to control how much scheduler and I/O bandwidth
programs in that container are allowed to use as well.

> 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.

I think we do have a way of doing that.  The kernel side support for
that is there, and a number of companies are using that to keep
programs from using too much physical memory.  What's missing is the
userspace tools to make the right thing happen automatically when you
double click on an "Open Office" or "Chrome" icon on your desktop.

       	     	   	 	    	     - Ted

  reply	other threads:[~2011-02-09 20:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-08 12:37 mmap, the language go, problems with the linux kernel martin capitanio
2011-02-08 13:26 ` Alan Cox
2011-02-12 14:28   ` Florian Weimer
2011-02-13  1:22     ` Ted Ts'o
2011-02-16 20:51       ` Florian Weimer
2011-02-08 16:23 ` Linus Torvalds
2011-02-09 16:30   ` Martin Capitanio
2011-02-09 16:40     ` Russ Cox
2011-02-09 19:17     ` Ted Ts'o
2011-02-09 19:56       ` [golang-dev] " Ian Lance Taylor
2011-02-09 20:11         ` Ted Ts'o [this message]
2011-02-16 18:16       ` Hannes Frederic Sowa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110209201108.GI9533@thunk.org \
    --to=tytso@mit.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=fullung@gmail.com \
    --cc=golang-dev@googlegroups.com \
    --cc=iant@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m@capitanio.org \
    --cc=rsc@golang.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox