From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <owner-linux-mm@kvack.org>
Received: from mail-pf0-f197.google.com (mail-pf0-f197.google.com [209.85.192.197])
	by kanga.kvack.org (Postfix) with ESMTP id 7DCD86B0005
	for <linux-mm@kvack.org>; Mon, 28 May 2018 11:54:25 -0400 (EDT)
Received: by mail-pf0-f197.google.com with SMTP id c187-v6so7585434pfa.20
        for <linux-mm@kvack.org>; Mon, 28 May 2018 08:54:25 -0700 (PDT)
Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15])
        by mx.google.com with ESMTPS id t19-v6si29589869plo.287.2018.05.28.08.54.24
        for <linux-mm@kvack.org>
        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Mon, 28 May 2018 08:54:24 -0700 (PDT)
Date: Mon, 28 May 2018 11:11:10 +0200
From: Michal Hocko <mhocko@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>
Sender: owner-linux-mm@kvack.org
List-ID: <linux-mm.kvack.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>

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