linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Hugh Dickins <hugh@veritas.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	Ben LaHaise <bcrl@redhat.com>,
	Rik van Riel <riel@conectiva.com.br>,
	Richard Jerrrell <jerrell@missioncriticallinux.com>,
	Stephen Tweedie <sct@redhat.com>,
	arjanv@redhat.com, alan@redhat.com, linux-mm@kvack.org
Subject: Re: [PATCH] swap_state.c thinko
Date: Fri, 6 Apr 2001 22:03:41 +0200	[thread overview]
Message-ID: <20010406220341.A935@athlon.random> (raw)
In-Reply-To: <Pine.LNX.4.21.0104061954470.1407-100000@localhost.localdomain>; from hugh@veritas.com on Fri, Apr 06, 2001 at 08:03:08PM +0100

On Fri, Apr 06, 2001 at 08:03:08PM +0100, Hugh Dickins wrote:
> On Fri, 6 Apr 2001, Andrea Arcangeli wrote:
> > On Fri, Apr 06, 2001 at 09:09:08PM +0200, Andrea Arcangeli wrote:
> > > We always overstimate anyways, we have to because we don't have information
> > > about the really freeable memory (think at the buffer cache pinned in the
> > 
> > ah, and btw, even if we would have information about the really freeable memory
> > in the cache and swap cache that would still useless in real life because we
> > don't reserve memory for the previous malloc calls (endless overcommit
> > discussion), so allocation could still fail during page fault and process will
> > have to be killed the linux way.
> 
> How indelicate you are!  I've been careful to avoid all mention of that...
> Seriously, there's good debate to have there, but it's another issue

This is not another issue. It is the same issue. If you don't do reservation
for the userspace memory you can only overstimate, if you understimate you are
wrong because you are not even able to use all the resources in your machine
and that is the current bug (while overstimating and overcommit may allow you
to better optimize the memory usage with the downside that you can have to kill
a task during a page fault and that is why it should be optional behaviour).

So I repeat: if you don't reserve the memory to make sure you will always be
able to allocate the malloced memory you just overstimate, and so the
vm_enough_memory automatically become a very imprecise guess, it's an heuristic
that is only meant to avoid ridicolous big allocations and that must _never_
understimate.

This is my last email about this issue.

Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

  reply	other threads:[~2001-04-06 20:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-05 15:56 Ben LaHaise
2001-04-05 16:05 ` Rik van Riel
2001-04-05 17:11   ` Ben LaHaise
2001-04-05 23:40     ` Andrea Arcangeli
2001-04-06  0:32     ` Linus Torvalds
2001-04-06 16:31       ` Hugh Dickins
2001-04-06 17:21         ` Linus Torvalds
2001-04-06 18:23           ` Hugh Dickins
2001-04-06 18:57             ` Linus Torvalds
2001-04-06 19:06               ` Rik van Riel
2001-04-06 18:47           ` Andrea Arcangeli
2001-04-06 18:37             ` Hugh Dickins
2001-04-06 19:09               ` Andrea Arcangeli
2001-04-06 18:53                 ` Hugh Dickins
2001-04-06 19:14                 ` Andrea Arcangeli
2001-04-06 19:03                   ` Hugh Dickins
2001-04-06 20:03                     ` Andrea Arcangeli [this message]
2001-04-06 19:12               ` Richard Jerrell
2001-04-06 19:52               ` Linus Torvalds
2001-04-06 20:22                 ` Andrea Arcangeli
2001-04-06 21:04                   ` Rik van Riel
2001-04-07  1:27                     ` Andrea Arcangeli
2001-04-09 18:16                   ` Alan Cox
2001-04-09 18:45                     ` Andrea Arcangeli
2001-04-09 20:32                     ` Linus Torvalds
2001-04-09 20:54                       ` David L. Parsley
2001-04-10 21:07                       ` James Antill
2001-04-10 22:20                         ` Jeff Garzik
2001-04-06 20:48                 ` Hugh Dickins
2001-04-05 17:21 ` Hugh Dickins
2001-04-05 21:39   ` Richard Jerrell
2001-04-06 20:20 Bulent Abali
2001-04-06 20:33 ` Jeff Garzik

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=20010406220341.A935@athlon.random \
    --to=andrea@suse.de \
    --cc=alan@redhat.com \
    --cc=arjanv@redhat.com \
    --cc=bcrl@redhat.com \
    --cc=hugh@veritas.com \
    --cc=jerrell@missioncriticallinux.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox