Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp782224pxb; Tue, 19 Oct 2021 12:54:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKnqWVq1UOoYofNgnL8NCMNuM1NnzA7IbD0FKAHMOFkkx/hIJ808voKdaHFpWr2LMqz6NF X-Received: by 2002:a17:906:5e01:: with SMTP id n1mr42415839eju.385.1634673281260; Tue, 19 Oct 2021 12:54:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634673281; cv=none; d=google.com; s=arc-20160816; b=hgqcuPuPQ3AsXcZxEizcGX+S0iY8017BTpGDlfSUAHrE5zctw/qvTT2i9e3bJua+0l veZSiiJWu1PkDJaCVK4JMocBPL3ZbeV6C3qFamry1rxhAjhyNFupYy2nJy0xpQkiflbV C18+/Q5LyZqpis9cIc6AQRjJWhNVli5lgY1A0F9Yunmrn9GZOad+JKTmGofK6t7MgWLf 6kEuBIUutBtNHDppzYwT6ZhYv7CFhBsx5ekgf2MFbFXKZca9NnO6xr+8n25Df3RYMoXq avR70Gcv3bzUrQfbS3UD0WZCdAFt4OqLH9EnVFZlC/musl0IDb2uEIurrR+YmVireyNH PRnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=go5xDeJRprjHLRm5uoyFM3lEgG4nIDrA50auzFm9P54=; b=I6EMnott1+i9cl7CtrRLyYClthO6kLUIO199XSmJSBn/NgRBvNXUtYADOYnDFRVh+X mTJLYziXQLSHCs4Yr2tK6AasVG+kdJWRdbuKsK0pA0bbqEPYWcXHGcbI+9YYdz4aQOtZ U9oLop7IKywv2hgZ+uJqQlJSYLstng/7dFiwqlzndLRfq82DmgzSQKTgQV7Oop35/ViC J/8V6PUZsb0tjZfCvvy4gPFvtRAx2o0a8fWKhmHA5uzAceSBbgBsdxABmkwnLuibqdy3 +bfhO+nwDjO/ckeJcltSE5/1CuK7Ip0fSLVuDk/jyhm4Dm4SRdKy7I5Igj0vPRearNPY GvlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=korg header.b=TE+8q5G6; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y1si27503017ejk.130.2021.10.19.12.54.17; Tue, 19 Oct 2021 12:54:41 -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=@linux-foundation.org header.s=korg header.b=TE+8q5G6; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231738AbhJSTyE (ORCPT + 99 others); Tue, 19 Oct 2021 15:54:04 -0400 Received: from mail.kernel.org ([198.145.29.99]:57032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230147AbhJSTyD (ORCPT ); Tue, 19 Oct 2021 15:54:03 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D30336113B; Tue, 19 Oct 2021 19:51:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1634673110; bh=jGj86H0JaCzg0FpU/IIjOqXur5MOCHmg5HVDErAlS9c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=TE+8q5G6fg7FTvw+yGNn9m1udm/EaXQQxjSdnl2DK2j9ru/LUmoehpNnHbrC3ahjC L3ozhy5L4vY9OfwgTE/VfwTdlx7EA2Oi0pPjdAPUIGoqSfE9cYyVqOgIumoSSkTTZc rqu3KbK+HyM8WLPftcSg3LwtyGTSq5mEdyEezJdg= Date: Tue, 19 Oct 2021 12:51:47 -0700 From: Andrew Morton To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Vasily Averin , Roman Gushchin , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko , Muchun Song Subject: Re: [PATCH v3] memcg, kmem: further deprecate kmem.limit_in_bytes Message-Id: <20211019125147.0ad010f318bbd8233cadcdae@linux-foundation.org> In-Reply-To: <20211019153408.2916808-1-shakeelb@google.com> References: <20211019153408.2916808-1-shakeelb@google.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 19 Oct 2021 08:34:08 -0700 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. > > ... > > @@ -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); checkpatch said "ENOTSUPP is not a SUSV4 error code, prefer EOPNOTSUPP"?