From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S939813AbeE1P4W (ORCPT <rfc822;w@1wt.eu>);
        Mon, 28 May 2018 11:56:22 -0400
Received: from mx2.suse.de ([195.135.220.15]:44260 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1425245AbeE1PyW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 28 May 2018 11:54:22 -0400
Date: Mon, 28 May 2018 11:11:10 +0200
From: Michal Hocko <mhocko@kernel.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Greg Thelen <gthelen@google.com>, Johannes Weiner <hannes@cmpxchg.org>,
        Linux MM <linux-mm@kvack.org>, Cgroups <cgroups@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] memcg: force charge kmem counter too
Message-ID: <20180528091110.GG1517@dhcp22.suse.cz>
References: <20180525185501.82098-1-shakeelb@google.com>
 <20180526185144.xvh7ejlyelzvqwdb@esperanza>
 <CALvZod5yTxcuB_Aao-a0ChNEnwyBJk9UPvEQ80s9tZFBQ0cxpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CALvZod5yTxcuB_Aao-a0ChNEnwyBJk9UPvEQ80s9tZFBQ0cxpw@mail.gmail.com>
User-Agent: Mutt/1.9.5 (2018-04-13)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat 26-05-18 15:37:05, Shakeel Butt wrote:
> On Sat, May 26, 2018 at 11:51 AM, Vladimir Davydov
> <vdavydov.dev@gmail.com> wrote:
> > On Fri, May 25, 2018 at 11:55:01AM -0700, Shakeel Butt wrote:
> >> Based on several conditions the kernel can decide to force charge an
> >> allocation for a memcg i.e. overcharge memcg->memory and memcg->memsw
> >> counters. Do the same for memcg->kmem counter too. In cgroup-v1, this
> >> bug can cause a __GFP_NOFAIL kmem allocation fail if an explicit limit
> >> on kmem counter is set and reached.
> >
> > memory.kmem.limit is broken and unlikely to ever be fixed as this knob
> > was deprecated in cgroup-v2. The fact that hitting the limit doesn't
> > trigger reclaim can result in unexpected behavior from user's pov, like
> > getting ENOMEM while listing a directory. Bypassing the limit for NOFAIL
> > allocations isn't going to fix those problem.
> 
> I understand that fixing NOFAIL will not fix all other issues but it
> still is better than current situation. IMHO we should keep fixing
> kmem bit by bit.
> 
> One crazy idea is to just break it completely by force charging all the time.

What is the limit good for then? Accounting?

-- 
Michal Hocko
SUSE Labs