All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@elf.ucw.cz>
To: Robert Love <rml@tech9.net>
Cc: akpm@zip.com.au, riel@conectiva.com.br,
	linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: [PATCH] 2.5-rmap: VM strict overcommit
Date: Fri, 26 Jul 2002 12:31:04 +0200	[thread overview]
Message-ID: <20020726103104.GA279@elf.ucw.cz> (raw)
In-Reply-To: <1026928763.1116.11.camel@sinai>

Hi!


> diff -urN linux-2.5.26-rmap/Documentation/vm/overcommit-accounting linux/Documentation/vm/overcommit-accounting
> --- linux-2.5.26-rmap/Documentation/vm/overcommit-accounting	Wed Dec 31 16:00:00 1969
> +++ linux/Documentation/vm/overcommit-accounting	Wed Jul 17 10:45:47 2002
> @@ -0,0 +1,77 @@
> +The Linux kernel supports four overcommit handling modes
> +
> +0	-	Heuristic overcommit handling. Obvious overcommits of
> +		address space are refused. Used for a typical system. It
> +		ensures a seriously wild allocation fails while allowing
> +		overcommit to reduce swap usage.  This is the default.
> +
> +1	-	No overcommit handling. Appropriate for some scientific
> +		applications.
> +
> +2	-	(NEW) swapless strict overcommit. The total address space
> +		commit for the system is not permitted to exceed 95% of
> +		free memory. This mode utilizes the new stricter accounting
> +		but does not impose a very strict rule.  It is possible that
> +		the system could kill a process accessing pages in certain
> +		cases.  If mode 3 is too strict when no swap is	present
> +		this is the best you can do.
> +
> +3	-	(NEW) strict overcommit. The total address space commit
> +		for the system is not permitted to exceed swap + half ram.
> +		In almost all situations this means a process will not be
> +		killed while accessing pages but only by malloc failures
> +		that are reported back by the kernel mmap/brk code.

In what scenario can "strict overcommit" kill?

> +4	-	(NEW) paranoid overcommit. The total address space commit
> +		for the system is not permitted to exceed swap. The machine
> +		will never kill a process accessing pages it has mapped
> +		except due to a bug (ie report it!).

...and why is that scenario impossible on "paranoid overcommit"?
								Pavel
-- 
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

  reply	other threads:[~2002-07-26 10:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-17 17:59 [PATCH] 2.5-rmap: VM strict overcommit Robert Love
2002-07-26 10:31 ` Pavel Machek [this message]
2002-07-26 14:46   ` Alan Cox
2002-07-29 22:20     ` Pavel Machek
2002-07-30 17:49       ` Rik van Riel
2002-07-30 17:55       ` William Lee Irwin III
2002-07-30 20:09       ` Alan Cox

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=20020726103104.GA279@elf.ucw.cz \
    --to=pavel@elf.ucw.cz \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@conectiva.com.br \
    --cc=rml@tech9.net \
    --cc=torvalds@transmeta.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.