Date:	Fri, 04 Jul 2008 08:50:47 +0530
From:	Balbir Singh <balbir@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	Hugh Dickins <hugh@...itas.com>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 2.6.26-rc8-mm1] memrlimit: fix mmap_sem deadlock

Andrew Morton wrote:
> On Fri, 04 Jul 2008 07:19:45 +0530 Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> 
>> Andrew Morton wrote:
>>> There doesn't seem to have been much discussion regarding your recent
>>> objections to the memrlimit patches.  But it caused me to put a big
>>> black mark on them.  Perhaps sending it all again would be helpful.
>> Black marks are not good, but there have been some silly issues found with them.
>> I have been addressing/answering concerns raised so far. Would you like me to
>> fold all patches and fixes and send them out for review again?
>>
>>
> 
> I was referring to the below (which is where the conversation ended).
> 
> It questions the basis of the whole feature.
> 

In the email below, I referred to Hugh's comment on tracking total_vm as a more
achievable target and it gives a rough approximation of something worth
limiting. I agree with him on those points and mentioned my motivation for the
memrlimit patchset. We also look forward to enhancing memrlimit to control
mlock'ed pages (as it provides the generic infrastructure to control RLIMIT'ed
resources). Given Hugh's comment, I looked at it from the more positive side
rather the pessimistic angle. I've had discussions along these lines with Paul
Menage and Kamezawa. In the past we've discussed and there are cases where
memrlimit is not useful (large VM allocations with sparse usage), but there are
cases as mentioned below in the motivation for memrlimits as to why and where
they are useful.

If there are suggestions to help improve the feature or provide similar
functionality without the noise; I am all ears

> 
> On Wed, 25 Jun 2008 06:31:05 +0530 Balbir Singh <balbir@...ux.vnet.ibm.com> wrote:
> 
>> Hugh Dickins wrote:
>>
>> ...
>>
>>> (In passing, I'll add that I'm not a great fan of these memrlimits:
>>> to me it's loony to be charging people for virtual address space,
>>> it's _virtual_, and process A can have as much as it likes without
>>> affecting process B in any way.  You're following the lead of RLIMIT_AS,
>>> but I've always thought RLIMIT_AS a lame attempt to move into the mmap
>>> decade, after RLIMIT_DATA and RLIMIT_STACK no longer made sense.
>>>
>>> Taking Alan Cox's Committed_AS as a limited resource charged per mm makes
>>> much more sense to me: but yes, it's not perfect, and it is a lot harder
>>> to get its accounting right, and to maintain that down the line.  Okay,
>>> you've gone for the easier option of tracking total_vm, getting that
>>> right is a more achievable target.  And I accept that I may be too
>>> pessimistic about it: total_vm may often enough give a rough
>>> approximation to something else worth limiting.)
>> You seem to have read my mind, my motivation for memrlimits is
>>
>> 1. Administrators to set a limit and be sure that a cgroup cannot consume more
>> swap + RSS than the assigned virtual memory limit
>> 2. It allows applications to fail gracefully or decide what parts to free up
>> to get more memory or change their allocation pattern (a scientific application
>> deciding what size of matrix to allocate for example).
>>


-- 
	Warm Regards,
	Balbir Singh
	Linux Technology Center
	IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists