Messages in this thread | | | From | James Sutherland <> | Subject | Re: Overcommitable memory?? | Date | Tue, 21 Mar 2000 23:56:22 +0000 |
| |
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/
| |