At Sun, 9 May 2004 19:39:59 +0200,
Vincent Lefevre wrote:
Second, I for one would consider the absence of overcommitment as a
bad misfeature. Good luck with the kernel bug report.
The 2.6 kernel seems to have better memory handling (but I couldn't
try yet). Concerning the 2.4 kernel, the
On 2004-05-16 00:09:28 +0900, GOTO Masanori wrote:
2.4 is starting the handover process to 2.6 with its role of stable
version. So if you want to fix 2.4 kernel documents, please do.
I posted a message to the linux-kernel mailing-list, but people there
are quite ignorant about the C language.
At Sun, 9 May 2004 19:39:59 +0200,
Vincent Lefevre wrote:
Second, I for one would consider the absence of overcommitment as a
bad misfeature. Good luck with the kernel bug report.
The 2.6 kernel seems to have better memory handling (but I couldn't
try yet). Concerning the 2.4 kernel, the
On 2004-05-16 00:09:28 +0900, GOTO Masanori wrote:
2.4 is starting the handover process to 2.6 with its role of stable
version. So if you want to fix 2.4 kernel documents, please do.
I posted a message to the linux-kernel mailing-list, but people there
are quite ignorant about the C language.
On 2004-05-09 14:16:13 -, [EMAIL PROTECTED] wrote:
In general, if you want malloc to return NULL on Linux in a controlled
way, the best advice is to use ulimit -v IMHO.
No, this is really a very bad idea, as this would limit the virtual
memory, instead of checks being done
In general, if you want malloc to return NULL on Linux in a controlled
way, the best advice is to use ulimit -v IMHO.
No, this is really a very bad idea, as this would limit the virtual
memory, instead of checks being done dynamically.
Oh, so you're adding/removing physical memory
Oh, so you're adding/removing physical memory dynamically?
No. I don't see why you ask this. In my documentation, ulimit sets
a limit for the *current* process, not for the whole system.
I know, but see /etc/initscript. Together with the number of
processes (also ulimited), it effectively
Wolfram Gloger wrote:
[ ] In my documentation, ulimit sets
a limit for the *current* process, not for the whole system.
I know, but see /etc/initscript. Together with the number of
processes (also ulimited), it effectively is a limit for the system.
Not the one you like, obviously, but
On 2004-05-09 17:03:13 +0200, Wolfram Gloger wrote:
I know, but see /etc/initscript. Together with the number of
processes (also ulimited), it effectively is a limit for the system.
Not the one you like, obviously, but nevertheless a functional one.
Definitely not realistic. I don't want to
I am not sure how one could describe a system crippled in this way as
functional. The limit itself would indeed be functional,
Ok. You could have stopped there. This is going to be my last post
in this thread.
[begin historical analogy]
Using ulimit in this way would give one an
Hi,
Since I don't know enough to continue this discussion, I'm copying
someone who does!
I hope I can clear this up..
Wolfram, is there documentation describing the choice of MAP_NORESERVE
in glibc's malloc, or do you know someone else I should ask? Thanks in
advance.
The intention here
On 2004-05-08 15:13:40 +0200, Wolfram Gloger wrote:
But now concerning the bug report in question: I see no bug. The
MAP_NORESERVE does not matter here at all. Note that before malloc
hands out memory in a region allocated with MAP_NORESERVE, it _must_
call mprotect(...,
On Sat, May 08, 2004 at 05:02:14PM +0200, Vincent Lefevre wrote:
On 2004-05-08 15:13:40 +0200, Wolfram Gloger wrote:
But now concerning the bug report in question: I see no bug. The
MAP_NORESERVE does not matter here at all. Note that before malloc
hands out memory in a region allocated
On 2004-05-08 11:10:01 -0400, Daniel Jacobowitz wrote:
Does strace even show MAP_NORESERVE? I don't think the mmap call that
you're looking at is even the one which uses MAP_NORESERVE, since in
the copy of glibc source I'm looking at, that's only used for
allocating secondary arenas.
You're
Hi,
Since I don't know enough to continue this discussion, I'm copying
someone who does!
I hope I can clear this up..
Wolfram, is there documentation describing the choice of MAP_NORESERVE
in glibc's malloc, or do you know someone else I should ask? Thanks in
advance.
The intention here
On 2004-05-08 15:13:40 +0200, Wolfram Gloger wrote:
But now concerning the bug report in question: I see no bug. The
MAP_NORESERVE does not matter here at all. Note that before malloc
hands out memory in a region allocated with MAP_NORESERVE, it _must_
call mprotect(...,
On Sat, May 08, 2004 at 05:02:14PM +0200, Vincent Lefevre wrote:
On 2004-05-08 15:13:40 +0200, Wolfram Gloger wrote:
But now concerning the bug report in question: I see no bug. The
MAP_NORESERVE does not matter here at all. Note that before malloc
hands out memory in a region allocated
On 2004-05-08 11:10:01 -0400, Daniel Jacobowitz wrote:
Does strace even show MAP_NORESERVE? I don't think the mmap call that
you're looking at is even the one which uses MAP_NORESERVE, since in
the copy of glibc source I'm looking at, that's only used for
allocating secondary arenas.
You're
On 2004-05-06 19:05:53 -0400, Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE
On Fri, May 07, 2004 at 09:25:11AM +0200, Vincent Lefevre wrote:
On 2004-05-06 19:05:53 -0400, Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed,
On 2004-05-06 19:05:53 -0400, Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE
On Fri, May 07, 2004 at 09:25:11AM +0200, Vincent Lefevre wrote:
On 2004-05-06 19:05:53 -0400, Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed,
On 2004-05-06 13:45:45 +0900, GOTO Masanori wrote:
IIRC, this kind of OOM (Out Of Memory) situation has been discussed at
linux kernel related lists for a long time. Your sample code repeats
to issue mmap() and to fill the acquired pages until it got problem.
So kernel needs to detect the
On Thu, May 06, 2004 at 09:05:29AM +0200, Vincent Lefevre wrote:
In the 2.4 kernel documentation, Documentation/sysctl/vm.txt says:
overcommit_memory:
This value contains a flag that enables memory overcommitment.
When this flag is 0, the kernel checks before each malloc()
to see if
On Thu, May 06, 2004 at 10:34:05PM +0200, Vincent Lefevre wrote:
On 2004-05-06 12:25:19 -0400, Daniel Jacobowitz wrote:
Overcommit does not work properly in 2.4, though. GOTO-san is right -
from your description you want strict overcommit, i.e. the value of 2
for this flag. Some of the
On 2004-05-06 12:25:19 -0400, Daniel Jacobowitz wrote:
Overcommit does not work properly in 2.4, though. GOTO-san is right -
from your description you want strict overcommit, i.e. the value of 2
for this flag. Some of the 2.4-ac kernels had this. So does 2.6.
This is strange, because 3
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE flag is ignored.
This is precisely what I thought to be the bug in glibc: the fact
(at least with the 2.4 kernel) that this flag is
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE flag is ignored.
This is precisely what I thought to be the
Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
[...]
This is precisely what I thought to be the bug in glibc: the fact
(at least with the 2.4 kernel) that this flag is used by glibc.
On which documentation is glibc based (in particular, concerning
Processing commands for [EMAIL PROTECTED]:
severity 247300 normal
Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash
Severity set to `normal'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
severity 247300 normal
thanks
At Tue, 4 May 2004 14:41:22 +0200,
Vincent Lefevre wrote:
I've set the overcommit to 0, and the malloc() function never fails,
even when there isn't enough memory left, making processes crash when
they need memory they have already allocated.
never is actually
On 2004-05-06 13:45:45 +0900, GOTO Masanori wrote:
IIRC, this kind of OOM (Out Of Memory) situation has been discussed at
linux kernel related lists for a long time. Your sample code repeats
to issue mmap() and to fill the acquired pages until it got problem.
So kernel needs to detect the
On Thu, May 06, 2004 at 10:34:05PM +0200, Vincent Lefevre wrote:
On 2004-05-06 12:25:19 -0400, Daniel Jacobowitz wrote:
Overcommit does not work properly in 2.4, though. GOTO-san is right -
from your description you want strict overcommit, i.e. the value of 2
for this flag. Some of the
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE flag is ignored.
This is precisely what I thought to be the bug in glibc: the fact
(at least with the 2.4 kernel) that this flag is
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
On 2004-05-06 16:44:54 -0400, Daniel Jacobowitz wrote:
The documentation in the 2.4 kernel is, indeed, wrong IIRC.
BTW, from 2.6:
In mode 2 the MAP_NORESERVE flag is ignored.
This is precisely what I thought to be the
Daniel Jacobowitz wrote:
On Fri, May 07, 2004 at 12:58:28AM +0200, Vincent Lefevre wrote:
[...]
This is precisely what I thought to be the bug in glibc: the fact
(at least with the 2.4 kernel) that this flag is used by glibc.
On which documentation is glibc based (in particular, concerning
Processing commands for [EMAIL PROTECTED]:
severity 247300 normal
Bug#247300: libc6: malloc() never fails on 2.4 kernels, making processes crash
Severity set to `normal'.
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
severity 247300 normal
thanks
At Tue, 4 May 2004 14:41:22 +0200,
Vincent Lefevre wrote:
I've set the overcommit to 0, and the malloc() function never fails,
even when there isn't enough memory left, making processes crash when
they need memory they have already allocated.
never is actually
Package: libc6
Version: 2.3.2.ds1-12
Severity: grave
Justification: causes non-serious data loss
I've set the overcommit to 0, and the malloc() function never fails,
even when there isn't enough memory left, making processes crash when
they need memory they have already allocated.
I'm not sure
Package: libc6
Version: 2.3.2.ds1-12
Severity: grave
Justification: causes non-serious data loss
I've set the overcommit to 0, and the malloc() function never fails,
even when there isn't enough memory left, making processes crash when
they need memory they have already allocated.
I'm not sure
40 matches
Mail list logo
