James Sutherland <jas88@cam.ac.uk>:
> 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. There is NOTHING
> "broken" about that - it's a very reasonable behaviour.
>
> >>If you really want your code to occupy unused space, just touch the
> >>space when you allocate it. End of problem.
> >
> > Unless, of course, you want to do something other than have some
> > random process die when you run out of memory.
>
> They are not random. IF your process is too big to fit in the machine
> at the time you run it, it gets killed. Nothing wrong with that.
But at the time the process started it there was space. Some time later
your buggy process used up the rest and killed it.
> > given
> >
> > char *foo = malloc(GIGABYTE(1));
> >
> > it's a lot easier to check to see if that memory is there by doing
> >
> > if (foo == 0) {
> > /* our out of memory processing */
> > }
> >
> > than to do the suggested
> >
> > long q;
> >
> > for (q = 0; q < GIGABYTE(1); q += magic_number_to_dirty_pages)
> > foo[q] = 0;
> >
> > /* if we get here, the malloc worked. If we're really lucky,
> > enough of the system survived the memory allocation so that
> > we can continue. */
> >
> > or the slower
> >
> > memset(foo, 0, GIGABYTE(1));
> >
> > /* if we get here, the malloc worked. If we're really lucky,
> > enough of the system survived the memory allocation so that
> > we can continue. */
> >
> > methods for really and truly allocating memory.
>
> Question: WTF do you want to hog a huge block of memory you don't use?
> THAT, IMO, is a TRULY broken process. You are trying to write a memory
> leak!
Lets just say that it was going to be a large simulation and it was
initializing the data arrays.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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:34 EST