On Fri, 6 Apr 2001, Wayne Whitney wrote:
>
> As was pointed out to me in January, another solution for i386 would be to
> fix a maximum stack size and have the mmap() allocations grow downward
> from the "top" of the stack (3GB - max stack size). I'm not sure why that
> is not currently done.
> > note, though, that you *CAN* actually malloc a lot more than 1G: you
> > just have to avoid causing mmaps that chop your VM at
> > TASK_UNMAPPED_BASE:
>
> Neat trick. I didn't realize that you could avoid allocating the mmap()
> buffers for stdin and stdout.
noone ever said you had to use
On Fri, 6 Apr 2001, Mark Hahn wrote:
> note, though, that you *CAN* actually malloc a lot more than 1G: you
> just have to avoid causing mmaps that chop your VM at
> TASK_UNMAPPED_BASE:
Neat trick. I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.
As
> can get at most 2GB. Newer glibc's allow you to tune the definition
> of "small" via an environment variable.
eventually, perhaps libc will be smart enough to create
more arenas in mmaped space once sbrk fails. note, though,
that you *CAN* actually malloc a lot more than 1G: you just
have
In mailing-lists.linux-kernel, you wrote:
> Essentially, the problem can be summarized to be that on a machine
> with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
> for the memory in small ( <= 128k) chunks.
Take a look at this message by Szabolcs Szakacsits:
On Fri, Apr 06, 2001 at 10:06:47AM -0400, [EMAIL PROTECTED] wrote:
> Essentially, the problem can be summarized to be that on a machine
> with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
> for the memory in small ( <= 128k) chunks. I've enclosed some results
> and a
Hi. Im hoping someone on here can help me out. I posted something
similar to this back in June 2000 when I was on the 2.2.X line and
was waiting to see if the 2.4 kernel would provide a fix.
Essentially, the problem can be summarized to be that on a machine
with ample ram (2G, 4G,
Hi. Im hoping someone on here can help me out. I posted something
similar to this back in June 2000 when I was on the 2.2.X line and
was waiting to see if the 2.4 kernel would provide a fix.
Essentially, the problem can be summarized to be that on a machine
with ample ram (2G, 4G,
In mailing-lists.linux-kernel, you wrote:
Essentially, the problem can be summarized to be that on a machine
with ample ram (2G, 4G, etc), I am unable to malloc a gig if I ask
for the memory in small ( = 128k) chunks.
Take a look at this message by Szabolcs Szakacsits:
can get at most 2GB. Newer glibc's allow you to tune the definition
of "small" via an environment variable.
eventually, perhaps libc will be smart enough to create
more arenas in mmaped space once sbrk fails. note, though,
that you *CAN* actually malloc a lot more than 1G: you just
have to
On Fri, 6 Apr 2001, Mark Hahn wrote:
note, though, that you *CAN* actually malloc a lot more than 1G: you
just have to avoid causing mmaps that chop your VM at
TASK_UNMAPPED_BASE:
Neat trick. I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.
As was
note, though, that you *CAN* actually malloc a lot more than 1G: you
just have to avoid causing mmaps that chop your VM at
TASK_UNMAPPED_BASE:
Neat trick. I didn't realize that you could avoid allocating the mmap()
buffers for stdin and stdout.
noone ever said you had to use stdio.
On Fri, 6 Apr 2001, Wayne Whitney wrote:
As was pointed out to me in January, another solution for i386 would be to
fix a maximum stack size and have the mmap() allocations grow downward
from the "top" of the stack (3GB - max stack size). I'm not sure why that
is not currently done.
I'd
13 matches
Mail list logo
