Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp139800pxb; Mon, 18 Oct 2021 22:55:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwIe8t9JoncPuwno6SLrn8CuAUIXhYT05QvD86uLQ3YPKS/C4PY2mGDqVAgCv/w3qQkUWnn X-Received: by 2002:a05:6402:5215:: with SMTP id s21mr51355779edd.113.1634622940115; Mon, 18 Oct 2021 22:55:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634622940; cv=none; d=google.com; s=arc-20160816; b=DLb+T4vfmjpOEmN3kUQH07ZRw0shhlyQcq+Kd/Ta+d+nbPi6ypkYenveNsStH1WTBC ZG1zP1Q8FIp78GLoxrRYwF7wfXxD1+0Cx+bk2Ek5fmEW5IVJ7CBI7x9TZfOP1vjRUEyI CDErXUwGwRmjo/weS/fFgeoaH3r82cH8nx37vyxphqEKe7Bf/X/5+hM+wWWkgiBjLu3k KgCPYEgy6AoaJM08BFGTIsG9KiTy4lOVxL85HRtn1Gr10BF75wUCU7pN9Gr9n+ts3mc1 4FZ+Q956hJKgUMCtXa3kXcVuZ1xl2FfR8Iu88bZ1P6pucuO2G46cw6w/nE9q+NL39+/N 7flw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=hhQEzUyEKyXCEjjzkYdjEsFZ3KqkRdQuV0vIpz0DeEU=; b=jwNZCFDJxvIvdvQOv1Yt2Wt20+nkdxLmdEcmTSwAIANXG2q6ykOnX2L5TEDtROQvGi KWzSXRrjhax8yH9BdLxAfqAdVj4bTJ3MgaM4V5umJF7tm1ac9TLiICCPesAsDv8GEEOA ++cj5J9bleexgJ6XyBPSJifOFoBoJbM4L0g2nMVZVcSTs7ByBOxZKLkNDnSGZKa5NoxZ 1QdICdYGh7gZ7V7IJastCHkI440lVmlfTE2U4wThHiWZ0+obaKQL9USAskRQhjTt+3Ky RUQNWQ94tyUNitklNJDXThctPlOTJ/yZEOjsIe0UErMVd3vCa4j+H3IOCH143hBWHKo+ A8Ig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=8GjQYpKj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hb43si30339163ejc.773.2021.10.18.22.55.16; Mon, 18 Oct 2021 22:55:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=8GjQYpKj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233874AbhJSFyr (ORCPT + 99 others); Tue, 19 Oct 2021 01:54:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233786AbhJSFyo (ORCPT ); Tue, 19 Oct 2021 01:54:44 -0400 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A6A12C061745 for ; Mon, 18 Oct 2021 22:52:32 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id d131so3053797ybd.5 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=FJjaiC64R80CRr0pa67fhv5yXgNqokSgdfs/ym+DmDleVokdv4p0pfb+7xVhOHEebh t86mO7T6IMNQIHN4DRSm/9pfkWTyeePL8VtIonl0VCbKicWGMc/ZwP3u4VG1ttNXUrgw jPLQ9EMlN360owmMqORlF6d37KsP600OrPl2ozeE7Wi1NbzRdu7f8bgfa6J3LB0NZZfJ abH0PeoAFdphpAxTf/SILKEsovsRQpXJYEnE2FqkgiDWzqkkGuD/IIMpzkqjTEHI7K4O +PpU2ormvLRcLVEfDHpkXa35yNJtgPSPTEV6MIBIZKfAVlVUzx5OlEPY2drdI5xOVHEK xNew== X-Gm-Message-State: AOAM531xYhAgvmZ/R+k+SE2oyrorRXvzzn6GsiSCwFE8k81gWohO7vBR LelTJ4MO8QuZKzMghoLqqhv2tGo3FdK2klWXydnhma71qloZ1A== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >