From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Dave Hansen <dave@linux.vnet.ibm.com>,
Paul Menage <menage@google.com>,
Dave Hansen <haveblue@us.ibm.com>,
Andrea Righi <righi.andrea@gmail.com>,
Hugh Dickins <hugh@veritas.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [discuss] memrlimit - potential applications that can use
Date: Thu, 21 Aug 2008 15:56:41 +0530 [thread overview]
Message-ID: <48AD42E1.40204@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080821164339.679212b2.kamezawa.hiroyu@jp.fujitsu.com>
KAMEZAWA Hiroyuki wrote:
> On Thu, 21 Aug 2008 08:55:52 +0530
> Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
>
>>>>> So, before we expand the use of those features to control groups by
>>>>> adding a bunch of new code, let's make sure that there will be users
>>>> for
>>>>> it and that those users have no better way of doing it.
>>>> I am all ears to better ways of doing it. Are you suggesting that overcommit was
>>>> added even though we don't actually need it?
>>> It serves a purpose, certainly. We have have better ways of doing it
>>> now, though. "i>>?So, before we expand the use of those features to
>>> control groups by adding a bunch of new code, let's make sure that there
>>> will be users for it and that those users have no better way of doing
>>> it."
>>>
>>> The one concrete user that's been offered so far is postgres. I've
>> No, you've been offered several, including php and apache that use memory limits.
>>
>>> suggested something that I hope will be more effective than enforcing
>>> overcommit.
>
> I'm sorry I miss the point. My concern on memrlimit (for overcommiting) is that
> it's not fair because an application which get -ENOMEM at mmap() is just someone
> unlucky.
It can happen today with overcommit turned on. Why is it unlucky?
I think it's better to trigger some notifier to application or daemon
> rather than return -ENOMEM at mmap(). Notification like "Oh, it seems the VSZ
> of total application exceeds the limit you set. Although you can continue your
> operation, it's recommended that you should fix up the situation".
> will be good.
>
So you are suggesting that when we are running out of memory (as defined by our
current resource constraints), we don't return -ENOMEM, but instead we now
handle a new event that states that we are running out of memory?
NOTE: I am not opposed to the event, it can be useful for container
administrators to know how to size their containers, not to application
developers who want to auto-tune their applications (see my comment on autonomic
computing in an earlier thread) or to applications that want to make sure they
don't OOM without the system administrator having to do oom_adj for every
important application.
> Thanks,
> -Kame
>
--
Balbir
--
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>
next prev parent reply other threads:[~2008-08-21 10:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 7:18 Balbir Singh
2008-08-19 15:58 ` Dave Hansen
2008-08-19 16:45 ` Balbir Singh
2008-08-19 17:41 ` Dave Hansen
2008-08-20 8:26 ` Balbir Singh
2008-08-20 16:29 ` Dave Hansen
2008-08-21 3:25 ` Balbir Singh
2008-08-21 7:43 ` KAMEZAWA Hiroyuki
2008-08-21 10:26 ` Balbir Singh [this message]
2008-08-21 10:59 ` KAMEZAWA Hiroyuki
2008-08-21 11:13 ` Balbir Singh
2008-08-21 15:18 ` righi.andrea
2008-08-20 13:25 ` righi.andrea
2008-08-20 16:38 ` Dave Hansen
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=48AD42E1.40204@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dave@linux.vnet.ibm.com \
--cc=haveblue@us.ibm.com \
--cc=hugh@veritas.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=menage@google.com \
--cc=righi.andrea@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox