public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: "H. J. Lu" <hjl@lucon.org>
To: linux-ia64@vger.kernel.org
Subject: Re: Virtual memory leaking through IA32 emulation layer for mmap and munmap
Date: Mon, 08 Mar 2004 23:59:15 +0000	[thread overview]
Message-ID: <20040308235915.GA2785@lucon.org> (raw)
In-Reply-To: <Pine.LNX.4.58.0403091028060.22838@sutekh.progsoc.uts.edu.au>

On Tue, Mar 09, 2004 at 10:43:45AM +1100, Shaun wrote:
> 
> Hi,
> 
> I'm not sure if this is a known issue or not, but we have been having some
> trouble running some of our programs under the IA32 emulation layer of
> linux-ia64.
> 
> What is happening in our case is that our program is indirectly causing
> lots of mmaps of anonymous memory for 4096 bytes. Shortly thereafter these
> blocks are munmaped. The munmap is effectively ignored causing the program
> to leak a page (16K in our kernel) of virtual memory.
> 
> The situation can be illustrated with the following code when compiled on
> an IA32 system then run on a IA64 system:
> 
> for (int i = 0; i < 10000; i++)
> {
>    pvAddr = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE,
>                  MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
>    printf("%p\n", pvAddr);
>    munmap(pvAddr, getpagesize());
> }
> 
> Given that getpagesize() is hardcoded in glibc it returns 4096, the mmap

getpagesize () isn't hardcoded to 4K in glibc. You can change it with
AT_PAGESZ. The problem is the x86 executable is aligned at 4K page
size, which is specified by the i386 ABI. The dynamic linker in glibc
won't load the normal x86 executables with a bigger page size. I have
a glibc patch which allows >4K page size. It may work for you.


H.J.

  reply	other threads:[~2004-03-08 23:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-08 23:43 Virtual memory leaking through IA32 emulation layer for mmap and Shaun
2004-03-08 23:59 ` H. J. Lu [this message]
2004-03-09  0:11 ` Virtual memory leaking through IA32 emulation layer for mmap and munmap Peter Chubb
2004-03-09  0:23 ` David Mosberger
2004-03-09  0:26 ` Virtual memory leaking through IA32 emulation layer for mmap Shaun
2004-03-09  0:57 ` Virtual memory leaking through IA32 emulation layer for mmap and munmap Peter Chubb
2004-03-09  1:04 ` David Mosberger
2004-03-09 20:26 ` Virtual memory leaking through IA32 emulation layer for mmap Arun Sharma
2004-03-09 20:32 ` Arun Sharma
2004-03-10  3:58 ` Virtual memory leaking through IA32 emulation layer for mmap and munmap n0ano
2004-03-10  5:16 ` Virtual memory leaking through IA32 emulation layer for mmap Shaun
2004-03-10 17:47 ` David Mosberger
2004-03-10 19:35 ` Arun Sharma
2004-03-10 19:48 ` David Mosberger

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=20040308235915.GA2785@lucon.org \
    --to=hjl@lucon.org \
    --cc=linux-ia64@vger.kernel.org \
    /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