> while i have no fundamental solution to this fundamentally
> unsolvable problem, maybe there is something we could do to get
> applications cooperate better with the VM system. There is the
> example of AIX, where they have a signal (SIGNOMEM?) to nonfatally
> alert processes to free up memory. This approach is quite kludgy
> and an application never knows as much as the VM system about the
> state of memory usage.
SIGNOMEM is ugly - but assuming we implement this, things like X
could use it to free memory which isn't necessary.
Some editors could also catch this to save their open files before
anything bad may or may not happen (yes, ugly - but better than
loosing you work).
> But what about a new (?) approach, 'disposable mappings'. This
> would be a per-vma property, just like 'read-only' and
> 'grows-down', 'disposable' defines new behavior: the kernel is free
> to drop even dirty pages too from such a vma. libc could be one of
> the early users: the malloc cache has potentially many dirty pages
> which have no information content. Whenever a process accesses a
> 'disposed' vma, it gets a page-fault, and libc has to fix things up
> by newly allocating and mapping new memory. Another user could be X
> by marking it's internal, recreatable caches (which are dirty) as
> disposable.
If libc has to catch a page fault and pull apart thing in order to
work out which page it was, this code won't be portable across
architectures (I have code for manual paging on x86 somewhere). Also
- how does libc tell the application that this area of memory needs
to be recreated?
Also - how does this differ from above, assuming here libc catches
ENONMEM and free's the 'disposable mappings' itself?
-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/