From: Michal Hocko <mhocko@kernel.org>
To: Balbir Singh <bsingharora@gmail.com>
Cc: linux-mm <linux-mm@kvack.org>,
lsf-pc <lsf-pc@lists.linux-foundation.org>
Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018
Date: Thu, 22 Feb 2018 14:34:25 +0100 [thread overview]
Message-ID: <20180222133425.GI30681@dhcp22.suse.cz> (raw)
In-Reply-To: <CAKTCnzmsEhMYnAOtN+BtN_6bEa=+fTRYSjB+OR9isfzRruwA_Q@mail.gmail.com>
On Fri 23-02-18 00:23:53, Balbir Singh wrote:
> On Fri, Feb 23, 2018 at 12:03 AM, Michal Hocko <mhocko@kernel.org> wrote:
> > On Thu 22-02-18 13:54:46, Balbir Singh wrote:
> > [...]
> >> 2. Memory cgroups - I don't see a pressing need for many new features,
> >> but I'd like to see if we can revive some old proposals around virtual
> >> memory limits
> >
> > Could you be more specific about usecase(s)?
>
> I had for a long time a virtual memory limit controller in -mm tree.
> The use case was to fail allocations as opposed to OOM'ing in the
> worst case as we do with the cgroup memory limits (actual page usage
> control). I did not push for it then since I got side-tracked. I'd
> like to pursue a use case for being able to fail allocations as
> opposed to OOM'ing on a per cgroup basis. I'd like to start the
> discussion again.
So you basically want the strict no overcommit on the per memcg level?
I am really skeptical, to be completely honest. The global behavior is
not very usable in most cases already. Making it per-memcg will just
amplify all the issues (application tend to overcommit their virtual
address space). Not to mention that you cannot really prevent from the
OOM killer because there are allocations outside of the address space.
So if you want to push this forward you really need a very good existing
usecase to justifiy the change.
--
Michal Hocko
SUSE Labs
--
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:[~2018-02-22 13:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 2:54 Balbir Singh
2018-02-22 13:03 ` Michal Hocko
2018-02-22 13:23 ` Balbir Singh
2018-02-22 13:34 ` Michal Hocko [this message]
2018-02-22 22:01 ` virtual memory limits control (was Re: [Lsf-pc] [LSF/MM ATTEND] Attend mm summit 2018) Balbir Singh
2018-02-23 7:42 ` Michal Hocko
2018-02-25 23:08 ` 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=20180222133425.GI30681@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=bsingharora@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox