9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Devon H. O'Dell" <devon.odell@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] lowest valid stack address
Date: Wed,  2 Sep 2009 09:28:33 -0400	[thread overview]
Message-ID: <9ab217670909020628t15f58a3bj99210c287fa5e298@mail.gmail.com> (raw)
In-Reply-To: <64399b170909020101n10787c71qf10f9fd5147274e2@mail.gmail.com>

2009/9/2 Andrés Domínguez <andresdju@gmail.com>:
> 2009/9/2 erik quanstrom <quanstro@quanstro.net>:
>>
>> aside: from the overcommit vm discussion.
>> in http://9fans.net/archive/2000/06/634 rob
>> says that plan 9 doesn't overcommit vm.
>> what's the history here?
>
> Exactly two years ago you started a thread about
> memory overcommit. If I remember correctly, plan9
> overcommits vm. Few weeks later the Go program
> from gorka crashed while allocating the stack, maybe
> an overcommiting check was added, probably gorka
> knows.

No checks have been added. I started a rather active thread about this
a few months ago in attempt to figure out a way to `protect' from this
behavior starving the kernel of memory and thus panicking. I'll leave
it up to Elly to find some way to actually exploit this :). The
problem ended up being that I'd have to rework a lot of the slab
allocator, or do checks on every memory allocation, and I didn't want
to do that. More detailed info for those who care:

Lemma: In order to avoid overcommitting, we must impose limits on how
much memory may, in fact, be allocated. To make the implementation
provable, you must be able to assert that memory always comes from the
same spot, and you thus have a single path to follow into allocation.

Memory limits must be enforced based on real hardware in the system.
The issue here is that some slabs will always fill up
disproportionately to others. Thus, whichever limit you impose, slabs
must be growable. Thus:
 - Systemic limits require you to be able to migrate pages between zones.
 - Per-zone memory limits are silly because you have to be able to
migrate pages between zones,
 - Per-process and per-user memory limits are silly, though easier to
implement, because they add too much overhead to allocations and
frees.

Basically, it boils down to: If you want to implement this
effectively, the slab allocator needs to be reworked so that memory
zones can `steal' pages from other zones. If this is a real issue, I'm
happy to go take another stab at it: I stopped working on it last time
because it seemed most people found it a non-issue.

--dho

> Andrés
>
>



  parent reply	other threads:[~2009-09-02 13:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-01 15:08 erik quanstrom
2009-09-01 16:52 ` cinap_lenrek
2009-09-01 16:55   ` erik quanstrom
2009-09-01 17:47     ` erik quanstrom
2009-09-01 23:22       ` Russ Cox
2009-09-01 23:49         ` erik quanstrom
2009-09-01 23:59           ` Russ Cox
2009-09-02  0:18             ` Devon H. O'Dell
2009-09-02  8:01           ` Andrés Domínguez
2009-09-02  8:58             ` Gorka Guardiola
2009-09-02 13:32               ` erik quanstrom
2009-09-02 13:28             ` Devon H. O'Dell [this message]
2009-09-02 13:35               ` erik quanstrom
2009-09-02 14:17                 ` Devon H. O'Dell

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=9ab217670909020628t15f58a3bj99210c287fa5e298@mail.gmail.com \
    --to=devon.odell@gmail.com \
    --cc=9fans@9fans.net \
    /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;
as well as URLs for NNTP newsgroup(s).