All of lore.kernel.org
 help / color / mirror / Atom feed
* Maximizing brk() space on stock ia32 Linux 2.4.x
@ 2001-12-07 19:58 Wayne Whitney
  2001-12-07 20:15 ` arjan
  0 siblings, 1 reply; 3+ messages in thread
From: Wayne Whitney @ 2001-12-07 19:58 UTC (permalink / raw)
  To: LKML; +Cc: Allan Steel, Paul Sargent

Hello,

Given the limitation of running under a stock ia32 Linux 2.4.x kernel
(e.g. TASK_UNMAPPED_BASE = 0x40000000 and __PAGE_OFFSET = 0xC0000000), how
can one write a program in a way to maximize the address space available
for brk()?  For example:

1) With static linking and glibc there is still one mmap() mapping that
looks like this: "40000000-40001000 rw-p 00000000 00:00 0".  Someone once
commented that this is a buffer for stdio.  If so, how would one modify
glibc to move it (MAP_FIXED) or get rid of it?  Or would it be possible to
use an alternative libc and sidestep this issue?

2) If dynamic linking is required, it seems that one needs to intercept
all mmap() calls, for example to insert addresses and MAP_FIXED.  This
seems a bit tricky, since the dynamic loader uses mmap(), so probably
LD_PRELOAD would not work.  What would be required for this?

3) Alternatively, it seems like it would be enough for a single, large
brk() to be executed early in the startup of the program, before any
mmap()'s.  Then the mmap()'s would automatically get placed higher in the
address space.  Where would one need to put this brk() call?  Would having
2-3 GB mapped but untouched have negative VM consequences?

4) Lastly, it seems that executables by default load at 0x08000000.  How 
does one build an executable that loads at a lower address, e.g. 
0x00002000?  How low is safe to go?

It seems that both (2) and (4) are possible, as Paul Sargent's email "2GB
process crashing on 2.4.14" shows the /proc/<pid>/maps of a (binary-only)
program that does them.

Thanks, Wayne





^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Maximizing brk() space on stock ia32 Linux 2.4.x
  2001-12-07 19:58 Maximizing brk() space on stock ia32 Linux 2.4.x Wayne Whitney
@ 2001-12-07 20:15 ` arjan
  2001-12-07 20:22   ` Wayne Whitney
  0 siblings, 1 reply; 3+ messages in thread
From: arjan @ 2001-12-07 20:15 UTC (permalink / raw)
  To: whitney; +Cc: linux-kernel

In article <Pine.LNX.4.33.0112071128500.440-100000@mf1.private> you wrote:
> Hello,

> Given the limitation of running under a stock ia32 Linux 2.4.x kernel
> (e.g. TASK_UNMAPPED_BASE = 0x40000000 and __PAGE_OFFSET = 0xC0000000), how
> can one write a program in a way to maximize the address space available
> for brk()?  For example:

Try using the "hoard" preload library for malloc() 
Does wonders...

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Maximizing brk() space on stock ia32 Linux 2.4.x
  2001-12-07 20:15 ` arjan
@ 2001-12-07 20:22   ` Wayne Whitney
  0 siblings, 0 replies; 3+ messages in thread
From: Wayne Whitney @ 2001-12-07 20:22 UTC (permalink / raw)
  To: arjan; +Cc: LKML

On Fri, 7 Dec 2001 arjan@fenrus.demon.nl wrote:

> In article <Pine.LNX.4.33.0112071128500.440-100000@mf1.private> you wrote:
>
> > Given the limitation of running under a stock ia32 Linux 2.4.x kernel
> > (e.g. TASK_UNMAPPED_BASE = 0x40000000 and __PAGE_OFFSET = 0xC0000000), how
> > can one write a program in a way to maximize the address space available
> > for brk()?  For example:
> 
> Try using the "hoard" preload library for malloc() 
> Does wonders...

I'm sure it does wonders for malloc(), but I'm talking about programs that
use sbrk()/brk(), for whatever reason.  :-)  I suppose I could try reading
the source and documentation for "hoard" to see what it does.

Thanks, Wayne



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2001-12-07 20:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-12-07 19:58 Maximizing brk() space on stock ia32 Linux 2.4.x Wayne Whitney
2001-12-07 20:15 ` arjan
2001-12-07 20:22   ` Wayne Whitney

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.