lkml.org 
[lkml]   [2000]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Overcommitable memory??
On Wed, 22 Mar 2000, John Ripley wrote:

[...]
> > Do you pass arguments in registers, instead of stack?
>
> Preallocated memory, but yes it makes an assumption that the stack is in
> a fit state.

Preallocated, and *locked* in RAM. Remember, if you're low on swap,
it's better you don't page-fault. Under low swap condition, there's
no difference in accessing newly allocated pages or accessing previously
paged-out ones. Either way, to free dirty page-frames the system needs
to allocate more swap.

> > 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 not sure I understand what you mean by a "GC")

Garbage Collector (it was mentioned in previous messages...).
A GC() may run without knowing exaclty what the process was doing when
it received the signal. It has to be carefully designed NOT to access
paged out memory "objects" itself. I.e. it has to find all the information
it needs to select the victim(s) of the collection already there.

> This shows just how impractical it is to catch SIGBUS after malloc
> (which is just an mmap with large enough chunks).

Or later. It *may* work, provided that the signal arrives early enough.

A cooperative environment is assumed, anyway:
a runaway (or malicious) process will ignore it, and will quickly get all
the memory the other processes may free.

> Here's a short list of problems:
>
> - Signal handler may be paged out. Solution: mlock

Let me see: you have 100 processes, which will mlock() their handlers
(and part of their GC()s, at least); a waste of RAM (to save swap?);

> - Jump location variable may be paged out. Solution: mlock

the same

> - Object instance cleanup needed, with much care taken about concurrency
> issues.

and not accessing paged-out objects; a trivial object->freeable flag won't
do;

> - Hard to judge exactly where the fault occurred. Solution: COW all
> pages after malloc, as it can only then happen in that operation. This
> brings up:

no; later the system will steal page-frames from your allocated RAM, and
put your pages on swap; when you access them again, you fault; faults may
occur anytime, not just at malloc() time, unless you mlock();

> - Inefficient.
> - An absolute bastard to use. Especially if you're threaded
> (/impossible)

needs cooperation of all processes, or its pratically useless;

> It's quite ridiculous that anyone can advocate this kind of solution,
> really.

works only in a controlled environment: but then it's easier not to OOM
at all.

Far from a "ideal" solution. i'm afraid.

>
> --
> John Ripley, empeg Ltd.
> http://www.empeg.com
>

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

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