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 21:27:07 -0700	[thread overview]
Message-ID: <20080703212707.e0f6bbda.akpm@linux-foundation.org> (raw)
In-Reply-To: <486D970F.2000607@linux.vnet.ibm.com>

On Fri, 04 Jul 2008 08:50:47 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> > 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

Well I've never reeeeeeealy understood what the whole feature is for.

+Advantages of providing this feature
+
+1. Control over virtual address space allows for a cgroup to fail gracefully
+   i.e., via a malloc or mmap failure as compared to OOM kill when no
+   pages can be reclaimed.
+2. It provides better control over how many pages can be swapped out when
+   the cgroup goes over its limit. A badly setup cgroup can cause excessive
+   swapping. Providing control over the address space allocations ensures
+   that the system administrator has control over the total swapping that
+   can take place.

umm, OK.  I'm not sure _why_ someone would want to do that.  Perhaps
some use-cases would help motivate us.  Perhaps desriptions of
real-world operational problems would would be improved or solved were
this feature available to the operator.


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 21:27:07 -0700	[thread overview]
Message-ID: <20080703212707.e0f6bbda.akpm@linux-foundation.org> (raw)
In-Reply-To: <486D970F.2000607@linux.vnet.ibm.com>

On Fri, 04 Jul 2008 08:50:47 +0530 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> > 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

Well I've never reeeeeeealy understood what the whole feature is for.

+Advantages of providing this feature
+
+1. Control over virtual address space allows for a cgroup to fail gracefully
+   i.e., via a malloc or mmap failure as compared to OOM kill when no
+   pages can be reclaimed.
+2. It provides better control over how many pages can be swapped out when
+   the cgroup goes over its limit. A badly setup cgroup can cause excessive
+   swapping. Providing control over the address space allocations ensures
+   that the system administrator has control over the total swapping that
+   can take place.

umm, OK.  I'm not sure _why_ someone would want to do that.  Perhaps
some use-cases would help motivate us.  Perhaps desriptions of
real-world operational problems would would be improved or solved were
this feature available to the operator.

--
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  4:27 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
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 [this message]
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=20080703212707.e0f6bbda.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.