On Tue, 21 Mar 2000, James Sutherland wrote:
> On 21 Mar 2000 13:40:28 +0100, you wrote:
> >Den 20-Mar-00 18:44:28 skrev Horst von Brand følgende om "Re: Overcommitable memory?? ":
> >> Jesse Pollard <email@example.com> said:
> >> [...]
> >>> YOU ARN'T OOM - a specific user is out of resources, not a catastrophic
> >>> failure.
> >> If the user's programs get killed, they'll be pissed off.
> > And for a good reason too. So don't kill the user's programs. That's why
> >Jesse and others would really like per user memory quotas, just as you have
> >per user disk space quotas. If you can disable overcommit, the program is
> >in control of what happens when it can't get the amount of memory it would
> >like. If you also add per user memory quotas, the system administrator can
> >prevent a single user (or another finite number of users) from using all
> The process CAN be told there isn't enough memory to do what it wants.
> Just signal it (with a signal it can catch.) It can then use that
> signal to trigger garbage collection (if it's an ML or Java VM, for
> example), shrink the cache (an music player), reduce spare processes
> (Apache), whatever.
Interesting. The page fault routine should trigger a signal to the process
that caused its invocation. And what even makes you hope that that
process won't page fault again executing the signal handler (pieces of
code and data that have been much likely paged-out months ago)?
We are not short of memory. We're short of swap. paging-out is the problem,
> IMO, it's much better to get a signal which means "we're getting short
> of memory, folks", which can be handled in ONE place, rather than
> returning 0 as a pointer - which many apps then try to dereference,
> ending up segfaulting themselves anyway.
"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.
-- ____/ ____/ / / / / 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 firstname.lastname@example.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:33 EST