Messages in this thread | | | Date | Sun, 19 Mar 2000 21:19:28 +1200 | From | Chris Wedgwood <> | Subject | Re: On the issue of low memory situations |
| |
On Sat, Mar 18, 2000 at 11:07:52PM +0000, Nicholas Vinen wrote:
> Another libc issue. The way I see this working, you get SIGNMEM (or > whatever) then one of your options is to free some memory. However, when > you free() or delete [], pages are still allocated. A CLib call, similar > to "int flushheap()" will need to be implemented, which finds all pages in > the heap which are totally unallocated and uses some kind of syscall to > turn them back into COW pages (then returning the count, so you can tell > if you really managed to free any memory).
glibc2 already does this to a certain extent.
[...]
> SIGNMEM should also set some kind of global variable (similar to errno) > like "memdeficit" which is how many more pages would need to be freed to > continue, letting you decide by flushheap()'s return value whether your > program can continue or not. Also, during SIGNMEM on SMP systems, all > other processors must sleep. Otherwise the memory situation may not be > stable across its execution.
Purely userspace semantics and seems overly complex to me.
-cw
- 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/
| |