LWN: Comments on "The mempressure control group proposal"

The mempressure control group proposal

oak — 2013-01-19T16:04:23+00:00

If there's only single process in the group, it probably can have pretty good guess about its real memory usage and how much it can free memory, even when overcommit is enabled. But using groups to manage a single process (the process itself), seems a bit weird.

If controller is managing a group that contains also other processes, how often that kind of controller really knows how much memory the other processes use (in general that requires parsing SMAPS data from /proc/)?

I mean, if you need kernel to tell when the group uses more memory than controller has told the kernel it can use, and that comes as "surprise" to the controller, how it knows what it can do with the processes it's managing to free amount that approximates what kernel indicates to be needed?

To me it seems that at best it can request other processes to free memory and hope for the best... And if situation doesn't resolve, it of course can kill them.

useful to trigger gc in userspace?

renox — 2013-01-07T12:30:05+00:00

Yes, and hopefully it could be used to make application with GCs much better "good citizens" on a shared computer, see "Garbage Collection Without Paging" (their Linux patch was rejected)
http://lambda-the-ultimate.org/node/2391

useful to trigger gc in userspace?

ahornby — 2013-01-06T21:01:00+00:00

This is a potential route to remove the need for predetermined heap sizes in the JVM and other GC based systems. The low memory message for the control group would be an appropriate time to trigger a full compacting GC rather than once heap hits some arbitrary per process limit.