Re: Overcommitable memory??

From: James Sutherland (jas88@cam.ac.uk)
Date: Tue Mar 21 2000 - 18:56:22 EST


On Tue, 21 Mar 2000 11:39:26 -0800 (PST), you wrote:
>James Sutherland wrote:
>> On 20 Mar 2000 15:19:23 -0800, you wrote:
>>
>> >In article <linux.kernel.fr1ddskpd1mnfr9gvjmnm8op9237gq61pd@4ax.com>,
>> >James Sutherland <jas88@cam.ac.uk> wrote:
>> >
>> >>Unfortunately, this would break a lot of code which would depend on
>> >>the current (perfectly reasonable) implementation of malloc() and
>> >>stack space - namely, memory is only allocated when you use it.
>> >
>> > No, it wouldn't -- that code come pre-broken for your sysadminning
>> > dispair.
>>
>> You are free to rewrite it all to fit your own replacement API if you
>> like - that's the bit I'd try to avoid, though.
>
> Umm, do you have any experience at all with computer programming?
Yes.

> I'm asking this because your arguments increasingly sound like
> you've been living in a cave on the dark side of the moon for
> the past 40 years, and now you're trying to get a handle on this
> computer thing by reading back issues of WiReD and PC Computing.
Far from it. I get the impression that the opponents of
demand-allocated memory have been living on a BBC Micro for their
entire careers, and would like to have the same system under Unix...

> david parsons \bi/ shudder.
There are some circumstances where you DO want/need direct control
over memory allocation, stack size etc. Embedded apps, for example, as
discussed elsewhere in l-k. Desktop/server apps, OTOH, are not in this
category normally. An EXTENSION to the API to ALLOW this for apps
would be useful - changing the existing API to do this would be silly.

James.

-
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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:35 EST