All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: balbir@linux.vnet.ibm.com
Cc: Hugh Dickins <hugh@veritas.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2.6.26-rc8-mm1] memrlimit: fix mmap_sem deadlock
Date: Thu, 3 Jul 2008 19:01:23 -0700	[thread overview]
Message-ID: <20080703190123.1d72e9d1.akpm@linux-foundation.org> (raw)
In-Reply-To: <486D81B9.9030704@linux.vnet.ibm.com>

On Fri, 04 Jul 2008 07:19:45 +0530 Balbir Singh <balbir@linux.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.


On Wed, 25 Jun 2008 06:31:05 +0530 Balbir Singh <balbir@linux.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).
> 



WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: balbir@linux.vnet.ibm.com
Cc: Hugh Dickins <hugh@veritas.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2.6.26-rc8-mm1] memrlimit: fix mmap_sem deadlock
Date: Thu, 3 Jul 2008 19:01:23 -0700	[thread overview]
Message-ID: <20080703190123.1d72e9d1.akpm@linux-foundation.org> (raw)
In-Reply-To: <486D81B9.9030704@linux.vnet.ibm.com>

On Fri, 04 Jul 2008 07:19:45 +0530 Balbir Singh <balbir@linux.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.


On Wed, 25 Jun 2008 06:31:05 +0530 Balbir Singh <balbir@linux.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).
> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2008-07-04  2:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-03 20:50 [PATCH 2.6.26-rc8-mm1] memrlimit: fix mmap_sem deadlock Hugh Dickins
2008-07-03 20:50 ` Hugh Dickins
2008-07-03 23:01 ` Andrew Morton
2008-07-03 23:01   ` Andrew Morton
2008-07-04  1:49   ` Balbir Singh
2008-07-04  1:49     ` Balbir Singh
2008-07-04  2:01     ` Andrew Morton [this message]
2008-07-04  2:01       ` Andrew Morton
2008-07-04  3:20       ` Balbir Singh
2008-07-04  3:20         ` Balbir Singh
2008-07-04  4:27         ` Andrew Morton
2008-07-04  4:27           ` Andrew Morton
2008-07-04  7:07           ` Balbir Singh
2008-07-04  7:07             ` Balbir Singh
2008-07-04  1:49 ` Balbir Singh
2008-07-04  1:49   ` Balbir Singh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080703190123.1d72e9d1.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.