linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mark Hahn <hahn@coffee.psychology.mcmaster.ca>
To: Mark_H_Johnson@Raytheon.com
Cc: linux-mm@kvack.org, Wichert Akkerman <wichert@cistron.nl>
Subject: Re: Running out of memory in 1 easy step
Date: Fri, 15 Sep 2000 12:35:50 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.10.10009151225420.25442-100000@coffee.psychology.mcmaster.ca> (raw)
In-Reply-To: <OF197FE829.51802B4B-ON8625695B.0048CCDB@hou.us.ray.com>

> I hate to ask, but where is this behavior described?  I can't find any hint

I was wrong, probably remembering something from old HPUX/etc.
maybe even thinking of libefence.

> of this behavior in the man page. I'm concerned because we would not have
> taken the "guard pages" into account when sizing our application's memory
> usage. We have a real time application where we will also lock the pages

if Linux did guard pages, they would be irrelevant unless you were 
astonishingly naive about using mmap.  glibc, for instance, will mmap
large chunks, and for them, one virtual page is irrelevant.  you'd have
to be making individual O(pagesize) mmaps for this to matter...

> into memory - running out of physical memory in this case is "very bad".

in any case, such (hypothetical on Linux) guard pages would be virtual,
not backed by physical memory.

#include <stdio.h>
#include <sys/mman.h>

char *
mmalloc(unsigned size) {
    char *p = (char*) mmap(0, 
			   size, 
			   PROT_READ|PROT_WRITE, 
			   MAP_PRIVATE|MAP_ANONYMOUS, 
			   0, 
			   0);
    if (p == MAP_FAILED)
	return 0;
    return p;
}
int
main() {
    const unsigned size = 4096;
    char *p = mmalloc(size);
    for (unsigned i=0; i<20; i++) {
	char *n = mmalloc(size);
	printf("next at %p (del %d)\n",n,n-p);
	p = n;
    }
    return 0;
}

--
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:[~2000-09-15 16:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-15 13:22 Mark_H_Johnson
2000-09-15 16:35 ` Mark Hahn [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-09-15 16:53 Mark_H_Johnson
2000-09-14 12:59 Wichert Akkerman
2000-09-14 15:56 ` Andi Kleen
2000-09-14 16:08   ` Wichert Akkerman
2000-09-14 18:43     ` Andi Kleen
2000-09-14 19:20       ` Wichert Akkerman
2000-09-14 23:03         ` Mark Hahn

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=Pine.LNX.4.10.10009151225420.25442-100000@coffee.psychology.mcmaster.ca \
    --to=hahn@coffee.psychology.mcmaster.ca \
    --cc=Mark_H_Johnson@Raytheon.com \
    --cc=linux-mm@kvack.org \
    --cc=wichert@cistron.nl \
    /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