memrlimit controller merge to mainline

Balbir Singh balbir at
Fri Jul 25 05:30:55 PDT 2008

Paul Menage wrote:
> Hi Balbir,
> Andrew included the memrlimit controller in his latest set of patches
> to Linus for mainline.
> Although the memrlimit controller basically works as intended, my
> impression from the mini-summit on Tuesday is that our consensus is
> that this still doesn't have concrete practical use-cases yet:
> - avoiding swap over-use is better handled by the forthcoming swap controller
> - applications that can usefully handle mmap() returning NULL don't
> really exist yet (and since the system as a whole allows address space
> overcommit limits, if it was practical/useful to write such apps then
> presumably they would already exist)

There are applications that can/need to handle overcommit, just that we are not
aware of them fully. Immediately after our meeting, I was pointed to

> So I think we'd be complicating some of the vm paths in mainline with
> a feature that isn't likely to get a lot of real use.

I did disagree in the meeting and there is also the use case of the feature
forming the infrastructure for other rlimit controllers.

> What do you (and others on the containers list) think? Should we ask
> Andrew/Linus to hold off on this for now? My preference would be to do
> that until we have someone who can stand up with a concrete scenario
> where they want to use this in a real environment.

While we can argue about use cases, the feature needs more testing and I am OK
holding off/reverting the merge to make it more stable and that would give us
more time to argue on its usefulness. To say that overcommit handling is not
useful is wrong. Meanwhile, I'll go back and look at the bug report that Hugh
has posted and also look at building an mlock controller on top of memrlimits.

	Warm Regards,
	Balbir Singh
	Linux Technology Center

More information about the Containers mailing list