From: Michal Hocko <mhocko@suse.com>
To: Vasily Averin <vvs@virtuozzo.com>
Cc: Shakeel Butt <shakeelb@google.com>,
Cgroups <cgroups@vger.kernel.org>, Linux MM <linux-mm@kvack.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [PATCH 0/9] memcg accounting from OpenVZ
Date: Wed, 10 Mar 2021 11:41:07 +0100 [thread overview]
Message-ID: <YEiiQ2TGnJcEtL3d@dhcp22.suse.cz> (raw)
In-Reply-To: <ad68d004-fa84-3d21-60b7-d4a342ad4007@virtuozzo.com>
On Wed 10-03-21 13:17:19, Vasily Averin wrote:
> On 3/10/21 12:12 AM, Shakeel Butt wrote:
> > On Tue, Mar 9, 2021 at 12:04 AM Vasily Averin <vvs@virtuozzo.com> wrote:
> >>
> >> OpenVZ many years accounted memory of few kernel objects,
> >> this helps us to prevent host memory abuse from inside memcg-limited container.
> >>
> >
> > The text is cryptic but I am assuming you wanted to say that OpenVZ
> > has remained on a kernel which was still on opt-out kmem accounting
> > i.e. <4.5. Now OpenVZ wants to move to a newer kernel and thus these
> > patches are needed, right?
>
> Something like this.
> Frankly speaking I badly understand which arguments should I provide to upstream
> to enable accounting for some new king of objects.
>
> OpenVZ used own accounting subsystem since 2001 (i.e. since v2.2.x linux kernels)
> and we have accounted all required kernel objects by using our own patches.
> When memcg was added to upstream Vladimir Davydov added accounting of some objects
> to upstream but did not skipped another ones.
> Now OpenVZ uses RHEL7-based kernels with cgroup v1 in production, and we still account
> "skipped" objects by our own patches just because we accounted such objects before.
> We're working on rebase to new kernels and we prefer to push our old patches to upstream.
That is certainly an interesting information. But for a changelog it
would be more appropriate to provide information about how much memory
user can induce and whether there is any way to limit that memory by
other means. How practical those other means are and which usecases will
benefit from the containment.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2021-03-10 10:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-09 8:03 Vasily Averin
2021-03-09 21:12 ` Shakeel Butt
2021-03-10 10:17 ` Vasily Averin
2021-03-10 10:41 ` Michal Hocko [this message]
2021-03-11 7:00 ` Vasily Averin
2021-03-11 8:35 ` Michal Hocko
[not found] ` <360b4c94-8713-f621-1049-6bc0865c1867@virtuozzo.com>
2021-03-15 13:27 ` [PATCH v2 8/8] memcg: accounting for ldt_struct objects Borislav Petkov
2021-03-15 15:48 ` Shakeel Butt
2021-03-15 15:58 ` Michal Hocko
2021-03-15 15:59 ` Borislav Petkov
[not found] ` <8196f732-718e-0465-a39c-62668cc12c2b@virtuozzo.com>
2021-03-15 15:14 ` [PATCH v2 2/8] memcg: accounting for ip6_dst_cache David Ahern
[not found] ` <cb893761-cf6e-fa92-3219-712e485259b4@virtuozzo.com>
2021-03-15 15:14 ` [PATCH v2 3/8] memcg: accounting for fib_rules David Ahern
[not found] ` <d569bf43-b30a-02af-f7ad-ccc794a50589@virtuozzo.com>
2021-03-15 15:15 ` [PATCH v2 4/8] memcg: accounting for ip_fib caches David Ahern
[not found] ` <4eb97c88-b87c-6f6e-3960-b1a61b46d380@virtuozzo.com>
2021-03-15 15:56 ` [PATCH v2 5/8] memcg: accounting for fasync_cache Shakeel Butt
[not found] ` <85b5f428-294b-af57-f496-5be5fddeeeea@virtuozzo.com>
2021-03-15 15:13 ` [PATCH v2 1/8] memcg: accounting for fib6_nodes cache David Ahern
2021-03-15 15:23 ` Shakeel Butt
2021-03-15 17:09 ` Jakub Kicinski
2021-03-15 19:24 ` Shakeel Butt
2021-03-15 19:32 ` Roman Gushchin
2021-03-15 19:35 ` Jakub Kicinski
2021-03-11 15:14 ` [PATCH 0/9] memcg accounting from OpenVZ Shakeel Butt
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=YEiiQ2TGnJcEtL3d@dhcp22.suse.cz \
--to=mhocko@suse.com \
--cc=cgroups@vger.kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-mm@kvack.org \
--cc=shakeelb@google.com \
--cc=vdavydov.dev@gmail.com \
--cc=vvs@virtuozzo.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