All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeelb@google.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Roman Gushchin <guro@fb.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux MM <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] memcg, kmem: further deprecate kmem.limit_in_bytes
Date: Wed, 18 Nov 2020 12:07:40 -0800	[thread overview]
Message-ID: <CALvZod4nG-6DBy_sJKbCg+xrYf1DS2ZJ3zkbHQSc4q8iZiPjwQ@mail.gmail.com> (raw)
In-Reply-To: <20201118195822.GW12284@dhcp22.suse.cz>

On Wed, Nov 18, 2020 at 11:58 AM Michal Hocko <mhocko@suse.com> wrote:
>
> On Wed 18-11-20 09:57:26, Shakeel Butt wrote:
> > The deprecation process of kmem.limit_in_bytes started with the commit
> > 0158115f702 ("memcg, kmem: deprecate kmem.limit_in_bytes") which also
> > explains in detail the motivation behind the deprecation. To summarize,
> > it is the unexpected behavior on hitting the kmem limit. This patch
> > moves the deprecation process to the next stage by disallowing to set
> > the kmem limit. In future we might just remove the kmem.limit_in_bytes
> > file completely.
> >
> > Signed-off-by: Shakeel Butt <shakeelb@google.com>
>
> I am not against this. I am just not sure whether one year is enough for
> those users who tend to have a more considervative kernel upgrade path.
> I am not worried about SLES user base much as we didn't even enable
> KMEM accounting when it was still guarded by a config option. Not sure
> about others though.
>
> Considering the code cleanup is not that large,

I was thinking of removing the kmem page counter in the followup but
thought of sending this alone to see if now is the right time.

> I would rather wait some
> more. But you can add
> Acked-by: Michal Hocko <mhocko@suse.com>
>
> Maybe we can ask Andrew to put it into mmotm for few releases.
>

Ok with me. I will send the full series and will ask Andrew to keep
the series in mm tree for a couple of releases.

  reply	other threads:[~2020-11-18 20:07 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-18 17:57 [PATCH] memcg, kmem: further deprecate kmem.limit_in_bytes Shakeel Butt
2020-11-18 17:57 ` Shakeel Butt
2020-11-18 19:46 ` Roman Gushchin
2020-11-18 19:54   ` Shakeel Butt
2020-11-18 19:54     ` Shakeel Butt
2020-11-18 19:58 ` Michal Hocko
2020-11-18 20:07   ` Shakeel Butt [this message]
2020-11-18 20:07     ` 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=CALvZod4nG-6DBy_sJKbCg+xrYf1DS2ZJ3zkbHQSc4q8iZiPjwQ@mail.gmail.com \
    --to=shakeelb@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.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 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.