Re: Overcommitable memory??

From: Marco Colombo (marco@esi.it)
Date: Wed Mar 22 2000 - 10:44:09 EST


On Wed, 22 Mar 2000, John Ripley wrote:

> James Sutherland wrote:
> > >"many apps" do not check malloc() return values? I don't call them apps,
> > >I call them first time students exercises. B-)
> > >They're are not able to check malloc() return value but they can setup a
> > >signal handler that triggers runtime a GC() clever enough not to page
> > >fault itself? I don't follow you.
> >
> > If they don't bother handling errors of either sort, they just get
> > terminated with a signal anyway. If they are careful enough to check
> > malloc() every time, they would handle SIGBUS as well.
>
> The problem here is the point at which you find you've run out of memory
> is not a point where you can back out safely. How would you do so
> anyway? Example without overcommit:
>
> main()
> {
> syscall_just_this_process_overcommit(0);
>
> char *p = (char *) malloc(1048576);
> if(!p) {
> printf("Hey we ran out of memory!\n");
> return ENOMEM;
> }
> // this memory is guaranteed safe to acces
> for(int i=0; i<1048576; i++) *p++ = i;
> // some other stuff...
> free(p);
> return 0;
> }
>
> To handle SIGBUS's is completely impractical. You would have to change
> the interrupted address to a bailout address. Example with overcommit:
>
> void *bailout_addr = NULL;
> void mysig() {
> if(bailout_addr)
> set_interrupted_address_somehow(bailout_addr);
> }
>
> main()
> {
> char *p = (char *) malloc(1048576);
> if(!p) goto bailout;
>
> bailout_addr = bailout;
> signal(SIGBUS, mysig);
> for(int i=0; i<1048576; i++) *p++ = i;
> // etc...
> free(p);
> return 0;
> bailout:
> printf("Hey we ran out of memory!\n");
> return ENOMEM;
> }

Nicely spotted.

> Ignore the fact printf can run out of memory - in one of the apps I've
> written I have a special version which can't.

Do you pass arguments in registers, instead of stack?

Are you sure the variable 'bailout_addr' does not belong to a page
that has been paged-out, at the time the signal-handler is invoked?

If your application just exits, you don't need to catch the signal,
you don't need the signal at all.

If is tries to do something useful, it has to be sure it won't cause
any other page-fault, or will make things just worse.

Unless the kernel starts sending signals when swap utilization exceeds
75%.

> Would you not agree that a SIGBUS is a completely silly way of finding
> out you didn't get your memory? Now imagine this in a threaded app.

You may start a GC() which does not need to know where you were when
you received the signal. Problem is that the GC() has little space
to run itself.

> I'm actually making a patch against 2.2.14 to test this out. I'll see
> what happens.
>
> --
> John Ripley, empeg Ltd.
> http://www.empeg.com
>
> -
> 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/
>

.TM.

-- 
      ____/  ____/   /
     /      /       /			Marco Colombo
    ___/  ___  /   /		      Technical Manager
   /          /   /			 ESI s.r.l.
 _____/ _____/  _/		       Colombo@ESI.it

- 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:36 EST