public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Ulrich Drepper <drepper@redhat.com>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@muc.de>
Subject: Re: hammer: MAP_32BIT
Date: Fri, 9 May 2003 11:20:27 +0200	[thread overview]
Message-ID: <20030509092026.GA11012@averell> (raw)
In-Reply-To: <3EBB5A44.7070704@redhat.com>

On Fri, May 09, 2003 at 09:35:32AM +0200, Ulrich Drepper wrote:
> It would be much better if there would also be a MAP_32PREFER flag with
> the appropriate semantics.  The failing mmap() calls seems to be quite
> expensive so programs with many threads are really punished a lot.

That's just an inadequate data structure. It does an linear search of the
VMAs and you probably have a lot of them. Before you add kludges like this 
better fix the data structure for fast free space lookup.

MAP_32BIT currently limits to the first 2GB only. That's needed because
most programs use it to allocate modules for the small code model and that
only supports 2GB (poster child for that is the X server) But for your 
application 4GB would be better. But adding another MAP_32BIT_4GB or so
would be quite ugly. I considered making the address where mmap starts searching
(TASK_UNMAPPED_BASE) settable using a prctl.

In some vendor kernels it's already in /proc/pid/mapped_base, but that is 
quite costly to change. That would probably give you the best of both, Just 
set it to a low value for the thread stacks and then reset it to the default.

I guess that would be the better solution for your stacks. 

-Andi

  reply	other threads:[~2003-05-09  9:08 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-09  7:35 hammer: MAP_32BIT Ulrich Drepper
2003-05-09  9:20 ` Andi Kleen [this message]
2003-05-09 11:28   ` mikpe
2003-05-09 11:38     ` Andi Kleen
2003-05-09 11:52       ` mikpe
2003-05-09 12:16         ` Andi Kleen
2003-05-09 18:11       ` H. Peter Anvin
2003-05-09 19:24         ` Ulrich Drepper
2003-05-09 20:55           ` H. Peter Anvin
2003-05-09 21:45             ` Ulrich Drepper
2003-05-09 22:07               ` H. Peter Anvin
2003-05-09 22:20                 ` Ulrich Drepper
2003-05-09 22:21                   ` H. Peter Anvin
2003-05-09 22:20               ` Timothy Miller
2003-05-09 22:20                 ` H. Peter Anvin
2003-05-09 22:46                   ` Timothy Miller
2003-05-09 23:24                     ` H. Peter Anvin
2003-05-13 14:25                       ` Timothy Miller
2003-05-09 22:22                 ` Ulrich Drepper
2003-05-09 22:53                   ` Timothy Miller
2003-05-09 23:24                     ` Ulrich Drepper
2003-05-10  0:00                       ` Edgar Toernig
2003-05-10  0:58                         ` Ulrich Drepper
2003-05-10  2:51                           ` Edgar Toernig
2003-05-09 17:36   ` H. Peter Anvin
2003-05-09 17:39   ` Ulrich Drepper
2003-05-10  1:48     ` Andi Kleen
2003-05-10 20:10       ` David Woodhouse
2003-05-13 18:54         ` H. Peter Anvin

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=20030509092026.GA11012@averell \
    --to=ak@muc.de \
    --cc=drepper@redhat.com \
    --cc=linux-kernel@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