> Actually, the default disposition for SIGDANGER is to ignore it.
> SIGDANGER can be caught, the idea being that they can try to log the fact,
> free memory or at least forego anything really memory-intensive in the near
> future. 'man 3 psdanger' on AIX show how to query the paging space on the
> system, as well as its proximity to the SIGDANGER and SIGKILL thresholds.
> I can see advantages to David's way, though--programs written without much
> care (buggy, bloated, memory hogs) have probably overlooked SIGDANGER and
> will be self-selected for reaping when memory gets tight.
--- All Linux apps currently overlook SIGDANGER. I don't think you mean to imply that all apps are buggy, bloated, memory hogs.
Adding the above type of handling would seem to require source changes to every app that wants take other than default memory handling.
I'd like to see a way to minimally impact 1st, source, 2nd, Binary compatibility. If we are out of non-RT signals, the 2nd may be unavoidable.
Perhaps the default with a SIGNMEM would be to ignore for legacy apps, so they would just 'hang' on a malloc waiting for memory. I dunno how many legacy apps are not written properly to handle an error condition back from malloc, But if that's thought to be a problem default could be set to ignore. Perhaps if the action if SIGNMEM was 'received' (but not caught) would be to return a failure from the operation that caused the SIGNMEM. The default behavior could be set, perhaps, via a /proc interface?
Ya know -- just as a point of amusement, WIN-CE has a 'SIGDANGER' type functionality -- when memory is low, it calls a 'low memory' handler in each app so they can release all the data they can, with, I believe, the default on no handler to be to do nothing. :-) Now if they could just get the random killing part down instead of suspending all processes and asking the user what processes to kill, they'd have pretty close to AIX functionality.
-- Linda A Walsh | Trust Technology, Core Linux, SGI firstname.lastname@example.org | Voice: (650) 933-5338
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:27 EST