From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F128C433F5 for ; Tue, 19 Oct 2021 05:52:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C44566115B for ; Tue, 19 Oct 2021 05:52:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org C44566115B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 60D716B0071; Tue, 19 Oct 2021 01:52:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BD2A6B0072; Tue, 19 Oct 2021 01:52:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 485A3900002; Tue, 19 Oct 2021 01:52:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 3BB596B0071 for ; Tue, 19 Oct 2021 01:52:34 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EC9DB39B09 for ; Tue, 19 Oct 2021 05:52:33 +0000 (UTC) X-FDA: 78712117386.13.3B5348F Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf20.hostedemail.com (Postfix) with ESMTP id D561AD0000AB for ; Tue, 19 Oct 2021 05:52:29 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id a7so1445023yba.6 for ; Mon, 18 Oct 2021 22:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hhQEzUyEKyXCEjjzkYdjEsFZ3KqkRdQuV0vIpz0DeEU=; b=8GjQYpKjvAO+JbTgbadd4Qpv0oYVQW5dLMGDgEVDqvaHL6WbpvpMzwRNiJHLxAVaXb lYxFY59tWmotTsbj3CGvxZ3s6AXrOyvXNkpsfaKIt7hwgO04SCFnoZuarqpRvGaQboj6 JPtTFD42/O2UOmNCTM8mKs3MTdBpYxvbpiQETy5yMbRT7P3WJtw+nqWWz/RJCNB0tFSD 8WehQP3Oc/7Pu2mSdAIGRWfKFpIRuRXdu2EklENy1Yhrs3+5Wu5cvZ4nsxZ7/5Rg+q6i m9NikMGLce+kWvRCBxXdYDBbe97Wm8ZaE7B2nce10OEn1VMblIWVJuVoTmPUa6F8HBL4 nipw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hhQEzUyEKyXCEjjzkYdjEsFZ3KqkRdQuV0vIpz0DeEU=; b=DVsfrTvMSpb7rG1WdMN/5hNHTjTJno47i9wbqIeNPq1hiPp9HFXnUPCx7yVffWSMYQ 6unCZXF1dCW3MZR4JgX9xI0gqXMIbBspBUAby4SRheR4+TUrl8nocWS/mmKh6f46wjs0 fZP2WLqp5HDxIkzdf2Qh+R6zcB65ZRib7MjP+G9Fs3FFog1BO7UXa6kfldrW/zS3tlIL Su0djxi8QsGsk6wtZswlXlXt76SU/d6bMFbEgFvOXw5vu9KD0iT99PLuFlZjG5RinMec eMKrqzuhYRJP3fXH2y1HVswYSpxwzDvVy5+2EfMmKUqbcv68deeMyUchGLjcuZXhP6N8 7ruQ== X-Gm-Message-State: AOAM532xFqBooOt5z4NhQJhdbdjDeLbDYcuwnWzZMsEI/3mlg//32VDi ggs7s+Iix1up29WOr64qcfKj0eoD/DxbpI0TDh8O+w== X-Google-Smtp-Source: ABdhPJytPBg2t7FEILWhgzh4fD7L32s4XWKCrqwC0E2FSf3XWTNjerbXi/5h/hgXLR1JJ9w/T0/WKNUi4U+3CMSPoVg= X-Received: by 2002:a25:aac4:: with SMTP id t62mr34689318ybi.419.1634622751860; Mon, 18 Oct 2021 22:52:31 -0700 (PDT) MIME-Version: 1.0 References: <20211019053058.2873615-1-shakeelb@google.com> In-Reply-To: <20211019053058.2873615-1-shakeelb@google.com> From: Muchun Song Date: Tue, 19 Oct 2021 13:51:55 +0800 Message-ID: Subject: Re: [PATCH v2] memcg, kmem: further deprecate kmem.limit_in_bytes To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Vasily Averin , Roman Gushchin , Andrew Morton , Cgroups , Linux Memory Management List , LKML , Michal Hocko Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: D561AD0000AB X-Stat-Signature: 6ywxudoyzsfm6osrr9y3fggamgf6yrw3 Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=8GjQYpKj; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf20.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-HE-Tag: 1634622749-709381 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 19, 2021 at 1:31 PM 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 > Acked-by: Roman Gushchin > Acked-by: Michal Hocko > Cc: Vasily Averin > Cc: Johannes Weiner > Cc: Andrew Morton > --- > Changes since v1: > - Replaced EINVAL with ENOTSUPP on setting kmem limits. > - V1 was posted last year at [0]. > > [0] https://lore.kernel.org/all/20201118175726.2453120-1-shakeelb@google.com/ > > .../admin-guide/cgroup-v1/memory.rst | 6 ++-- > mm/memcontrol.c | 35 +++---------------- > 2 files changed, 6 insertions(+), 35 deletions(-) > > diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst > index 41191b5fb69d..9be961521743 100644 > --- a/Documentation/admin-guide/cgroup-v1/memory.rst > +++ b/Documentation/admin-guide/cgroup-v1/memory.rst > @@ -87,10 +87,8 @@ Brief summary of control files. > memory.oom_control set/show oom controls. > memory.numa_stat show the number of memory usage per numa > node > - memory.kmem.limit_in_bytes set/show hard limit for kernel memory > - This knob is deprecated and shouldn't be > - used. It is planned that this be removed in > - the foreseeable future. > + memory.kmem.limit_in_bytes This knob is deprecated and writing to > + it will return -ENOTSUPP. > memory.kmem.usage_in_bytes show current kernel memory allocation > memory.kmem.failcnt show the number of kernel memory usage > hits limits Since memory.kmem.limit_in_bytes can not be set, how about removing those instructions as well? diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index 41191b5fb69d..f710f36770fa 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -518,11 +518,6 @@ will be charged as a new owner of it. charged file caches. Some out-of-use page caches may keep charged until memory pressure happens. If you want to avoid that, force_empty will be useful. - Also, note that when memory.kmem.limit_in_bytes is set the charges due to - kernel pages will still be seen. This is not considered a failure and the - write will still return success. In this case, it is expected that - memory.kmem.usage_in_bytes == memory.usage_in_bytes. - 5.2 stat file ------------- With this changes, Reviewed-by: Muchun Song Thanks. > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 8f1d9c028897..49a76049a885 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2999,7 +2999,6 @@ static void obj_cgroup_uncharge_pages(struct obj_cgroup *objcg, > static int obj_cgroup_charge_pages(struct obj_cgroup *objcg, gfp_t gfp, > unsigned int nr_pages) > { > - struct page_counter *counter; > struct mem_cgroup *memcg; > int ret; > > @@ -3009,21 +3008,8 @@ static int obj_cgroup_charge_pages(struct obj_cgroup *objcg, gfp_t gfp, > if (ret) > goto out; > > - if (!cgroup_subsys_on_dfl(memory_cgrp_subsys) && > - !page_counter_try_charge(&memcg->kmem, nr_pages, &counter)) { > - > - /* > - * Enforce __GFP_NOFAIL allocation because callers are not > - * prepared to see failures and likely do not have any failure > - * handling code. > - */ > - if (gfp & __GFP_NOFAIL) { > - page_counter_charge(&memcg->kmem, nr_pages); > - goto out; > - } > - cancel_charge(memcg, nr_pages); > - ret = -ENOMEM; > - } > + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) > + page_counter_charge(&memcg->kmem, nr_pages); > out: > css_put(&memcg->css); > > @@ -3715,17 +3701,6 @@ static void memcg_offline_kmem(struct mem_cgroup *memcg) > } > #endif /* CONFIG_MEMCG_KMEM */ > > -static int memcg_update_kmem_max(struct mem_cgroup *memcg, > - unsigned long max) > -{ > - int ret; > - > - mutex_lock(&memcg_max_mutex); > - ret = page_counter_set_max(&memcg->kmem, max); > - mutex_unlock(&memcg_max_mutex); > - return ret; > -} > - > static int memcg_update_tcp_max(struct mem_cgroup *memcg, unsigned long max) > { > int ret; > @@ -3791,10 +3766,8 @@ static ssize_t mem_cgroup_write(struct kernfs_open_file *of, > ret = mem_cgroup_resize_max(memcg, nr_pages, true); > break; > case _KMEM: > - pr_warn_once("kmem.limit_in_bytes is deprecated and will be removed. " > - "Please report your usecase to linux-mm@kvack.org if you " > - "depend on this functionality.\n"); > - ret = memcg_update_kmem_max(memcg, nr_pages); > + /* kmem.limit_in_bytes is deprecated. */ > + ret = -ENOTSUPP; > break; > case _TCP: > ret = memcg_update_tcp_max(memcg, nr_pages); > -- > 2.33.0.1079.g6e70778dc9-goog >