9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <forsyth@terzarima.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] plan 9 overcommits memory?
Date: Mon,  3 Sep 2007 22:16:17 +0100	[thread overview]
Message-ID: <a2892e3b0e181ecd5e6dd70ec7876525@terzarima.net> (raw)
In-Reply-To: <2c68bbb34242a932e4b3e9be554c6f18@quanstro.net>

> if we allow overcomitted memory, *any* access of brk'd memory might page
> fault.  this seems like a real step backwards in error recovery as most programs
> assume that malloc either returns n bytes of valid memory or fails.  since
> this assumption is false, either we need to make it true or fix most programs.

in the Inferno environment, i concluded that exceptions were the only way of handling
that (you could use notes in Plan 9), and that deals with both explicit
and implicit allocations.  it's more obvious in Inferno because implicit allocations
are common, because the run time system allocates memory dynamically, and not
just for stack frames.

the exception handlers are placed, optionally, fairly high up in the application processes, with further supervising sets
towards the root of the system (eg, to encapsulate individual applications within the window system).
an unhandled exception within an application process causes that process and perhaps others in its group
to die, and the exception is propagated to a process that's the nominated process group leader.

note that the process that incurs the exception is just the one that ran out of memory, not the one
that `really' caused the problem.  there needs to be some extra mechanism to ensure that important
functions survive in any case.

i looked at quota systems, but they are far too pessimistic for memory systems as they are for disc systems
(for most embedded devices, which is where you typically care most about this).
typically you end up with either over-committing (which is where we started), or poor utilisation
(which also isn't great for small embedded systems).

that left some form of allocation accounting, but we found that most programmers
for one reason or another found quite hard the systems analysis that's needed to make
allocation accounting work (although the degree of pessimism is typically much less
than that of quotas, which are too coarse-grained).

i used a variant that reserved a given amount of memory for use by distinguished processes
critical to system operation or recovery.   (perhaps this protected memory structure should have nested,
but it seemed better to see if that would really be useful.)

systems analysis at this level is much easier, though still neglected.



  parent reply	other threads:[~2007-09-03 21:16 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-03  3:38 geoff
2007-09-03  5:35 ` Scott Schwartz
2007-09-03  6:05   ` Uriel
2007-09-03 13:33   ` erik quanstrom
2007-09-03 17:09     ` john
2007-09-03 17:17       ` Gorka Guardiola
2007-09-03 17:25         ` Francisco J Ballesteros
2007-09-03 17:30         ` john
2007-09-03 19:47           ` Charles Forsyth
2007-09-03 19:46         ` Uriel
2007-09-03 19:54           ` Charles Forsyth
2007-09-03 19:54             ` Uriel
2007-09-03 20:34               ` geoff
2007-09-03 20:16             ` erik quanstrom
2007-09-03 17:32       ` erik quanstrom
2007-09-03 17:39         ` Francisco J Ballesteros
2007-09-03 17:43         ` john
2007-09-03 17:45           ` john
2007-09-03 19:52             ` Charles Forsyth
2007-09-05  8:33         ` sqweek
2007-09-04  8:48       ` Douglas A. Gwyn
2007-09-03 18:13   ` geoff
2007-09-03 20:17     ` erik quanstrom
2007-09-03 20:48       ` geoff
2007-09-03 22:01         ` erik quanstrom
2007-09-03 22:43           ` Charles Forsyth
2007-09-03 23:51             ` erik quanstrom
2007-09-04  0:04               ` Charles Forsyth
2007-09-04 14:44                 ` erik quanstrom
2007-09-04 15:07                   ` Charles Forsyth
2007-09-04 15:18                     ` ron minnich
2007-09-04 15:18                     ` Charles Forsyth
2007-09-05  8:48                       ` Douglas A. Gwyn
2007-09-05 10:53                         ` erik quanstrom
2007-09-06  8:42                           ` Douglas A. Gwyn
2007-09-06 17:15                             ` Joel C. Salomon
2007-09-06 19:38                               ` ron minnich
2007-09-06 20:18                                 ` Charles Forsyth
2007-09-06 23:37                                 ` Steve Simon
2007-09-07  3:09                                 ` Roman Shaposhnik
2007-09-07  4:09                                   ` Bruce Ellis
2007-09-07  4:25                                     ` Lyndon Nerenberg
2007-09-07  4:37                                       ` Bruce Ellis
2007-09-07  4:43                                         ` Lyndon Nerenberg
2007-09-10 15:24                                         ` roger peppe
2007-09-07 10:55                                     ` erik quanstrom
2007-09-04 23:32                     ` erik quanstrom
2007-09-03 21:16       ` Charles Forsyth [this message]
2007-09-03 21:19         ` ron minnich
2007-09-03 21:41           ` Eric Van Hensbergen
2007-09-03 21:51           ` erik quanstrom
2007-09-03 13:21 ` erik quanstrom
2007-09-03 14:01   ` Sape Mullender
2007-09-03 14:32     ` erik quanstrom
2007-09-03 15:28       ` Sape Mullender
2007-09-04  4:32         ` lucio
2007-09-04  7:23 ` Dave Eckhardt
2007-09-04  8:48 ` Douglas A. Gwyn
  -- strict thread matches above, loose matches on Subject: below --
2007-08-31 11:41 erik quanstrom
2007-09-02 21:27 ` Russ Cox
2007-09-03  0:43   ` erik quanstrom
2007-09-04  8:47     ` Douglas A. Gwyn
2007-09-04 13:39       ` David Leimbach
2007-09-04 14:41         ` erik quanstrom
2007-09-04 15:54           ` David Leimbach
2007-09-04 17:37     ` sqweek
2007-09-04 18:10       ` ron minnich
2007-09-04 18:53         ` sqweek
2007-09-03  1:23   ` Scott Schwartz
2007-09-03  1:47     ` ron minnich
2007-09-03  2:11       ` erik quanstrom
2007-09-03  2:11       ` erik quanstrom
2007-09-04  8:48         ` Douglas A. Gwyn
2007-09-03  5:28       ` Scott Schwartz

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=a2892e3b0e181ecd5e6dd70ec7876525@terzarima.net \
    --to=forsyth@terzarima.net \
    --cc=9fans@cse.psu.edu \
    /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).