lkml.org 
[lkml]   [2000]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Avoiding OOM on overcommit...?
From
Date
Marco Colombo writes:
> On 21 Mar 2000, Olaf Weber wrote:

>> On ther other hand, most programs do not use sbrk(2) to obtain memory,
>> they use malloc(3). The difference is that (following the C standard)
>> there is a guarantee that if malloc succeeds, then the memory can be
>> used. On a system that unconditionally overcommits, this guarantee
>> doesn't hold.

> Does the standard say something about paging? (I don't know, but i think no)
> Paging is transparent, until you *time* what you're doing. Then you'll
> see what the difference is between RAM and disk access time.

Etc. I think you're just being silly here, and know it.

> malloc() "allocates" memory only on its own opaque pool. It has no
> OS meaning.

Correct. But the C standard says that it has certain properties (and
implies some others). Basically, if I write a program and get reports
that it dies with a SIGBUS in some circumstances, I go on a bug-hunt
for the use of misaligned addresses and such. I would be very unhappy
to discover that I've been looking at a memory shortage masquerading
as a program bug. (I do test the return of malloc.) If the signal
sent had been (say) SIGNOMEM instead then I'd at least be spared that
particular incovenience.

> On systems with no protected memory (yes, you compile C programs on
> them) you can access every address you like. No need to malloc. You
> may write you own heap management routine. libc provides one. On
> system with memory protection, you can still write your own heap
> management routine, which uses whatever system call to do its jobs.
> malloc is a "standard" way to manage a heap.

If you want to write even moderately portable code, then you haven't
got many options besides trusting malloc. More sophisticated methods
of obtaining memory tend to differ between systems, and even between
different revisions of a system. Writing your own memory management
routines will (in portable code) typically be done _on top of_ malloc
rather than in stead of it.

Properly coping with memory that may not be there when it is used
requires special programming techniques. I'm not unwilling to use
such techniques, when appropriate, but not in all cases.

[...]

>> In any case, it seems people are now mostly shooting the same
>> arguments at each others. More constructive (but definitely more
>> work) would be to instrument a kernel to actually keep track of memory
>> in sufficient detail, and (for example) log messages when it is

> You're missing that an overcommitting MM system is more advanced than
> a nonovercommitting one. The kernel "keeps track of memory" the right way.

An overcommitting MM system _can be_ more advanced. It can also
overcommit because it cannot figure out how not do so. As far as I
can tell linux currently falls in the latter category: it cannot
tell to what extent memory has been overcommitted, nor does it allow
for selective overcommitment.

--
Olaf Weber

Do not meddle in the affairs of sysadmins,
for they are quick to anger and have no need for subtlety.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.144 / U:0.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site