Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp856849pxy;
        Wed, 5 May 2021 16:02:05 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzW4YakTukbQgcEHjbYWo9HKSRZErdt6tQpRwz3WMtiy7UfT3ZnyO8fHiMqOB2tBbHzWYgr
X-Received: by 2002:a17:902:d884:b029:ec:9fcd:2311 with SMTP id b4-20020a170902d884b02900ec9fcd2311mr1197511plz.80.1620255725580;
        Wed, 05 May 2021 16:02:05 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1620255725; cv=none;
        d=google.com; s=arc-20160816;
        b=d+XAAbWxXIUMfWnZwqlzUY+g3+y793LtZ/DDqSf2UHpRkLG/F4RJTzunAUMwCow2aV
         CB5FOUQiCL81y0Z92tk2F53tn3fSCR3hmWjoUaJkzw0IhoSVi9dI1UjWiTafvDTFRtTu
         G0/9r84aWVFloCi8vxq6MylRLwUoXuBdx0BRs+V6S98/IChGle2uBGmxF7zb69EMt3be
         LVvWSNAX2NWymRGnDRR8YAthgE2PaNwsfsBWBva634F+Rl8yRxR3DZIOQ/2pSyixeHPw
         nkMqjBmiGPH5ziVdZTPmNxzRkp9IXtOkuXUuwwcbEnlTZhbxjX7bkZEoKIX5d9j9yG2n
         yvZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-id:precedence:content-transfer-encoding:content-language
         :in-reply-to:mime-version:user-agent:date:message-id:from:references
         :cc:to:subject;
        bh=sCocTx3LbXnMmakisoSMCRewNzoonPbzXYRFgD19f3o=;
        b=lGLBsJZpNJj1GXxPyTpiEe8evM9LTb01Q1UgKxxiyHDJp5MFZtRX1kX1ot+0Bbb4JH
         f+oe4EqwGxfW3Ddv+oUfXWqTsSA3LJfDOvvrpDs1H4+hwt0fvAHnZUTnjfwpIt/poCD5
         orxuh1oZRw+CdOlAdQyMg/i2D8hcEpsdJ7aBSixHlHfonRKeqXZk4Bjaluyw4LurNmOa
         Nhkzc2+TaRNTnLrBHvX9v/3J2v4Ro1Z9WeUoU7QkfnEpVGJotLaVwNBYbhx3TEabVlf5
         M8qGwLdYwpqyvAqbNDIi126ziJCc+UBTvgMpxKWWSJICH4l3hxYtsDb2jjhKvSLnph/C
         /CZQ==
ARC-Authentication-Results: i=1; mx.google.com;
       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: <linux-kernel-owner@vger.kernel.org>
Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18])
        by mx.google.com with ESMTP id s3si837978pgs.326.2021.05.05.16.01.51;
        Wed, 05 May 2021 16:02:05 -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;
       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 S230243AbhEEVax (ORCPT <rfc822;lizhaoxin19940524@gmail.com>
        + 99 others); Wed, 5 May 2021 17:30:53 -0400
Received: from mx2.suse.de ([195.135.220.15]:55746 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S229893AbhEEVax (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 5 May 2021 17:30:53 -0400
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Received: from relay2.suse.de (unknown [195.135.221.27])
        by mx2.suse.de (Postfix) with ESMTP id 48846AFD5;
        Wed,  5 May 2021 21:29:55 +0000 (UTC)
Subject: Re: [PATCH v3 2/2] mm: memcg/slab: Create a new set of kmalloc-cg-<n>
 caches
To:     Roman Gushchin <guro@fb.com>
Cc:     Waiman Long <longman@redhat.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Michal Hocko <mhocko@kernel.org>,
        Vladimir Davydov <vdavydov.dev@gmail.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Christoph Lameter <cl@linux.com>,
        Pekka Enberg <penberg@kernel.org>,
        David Rientjes <rientjes@google.com>,
        Joonsoo Kim <iamjoonsoo.kim@lge.com>,
        Shakeel Butt <shakeelb@google.com>,
        linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
        linux-mm@kvack.org
References: <20210505154613.17214-1-longman@redhat.com>
 <20210505154613.17214-3-longman@redhat.com>
 <YJLWN6bNBYyKRPEN@carbon.DHCP.thefacebook.com>
 <235f45b4-2d99-f32d-ac2b-18b59fea5a25@suse.cz>
 <YJLk1tmDeGed58yr@carbon.dhcp.thefacebook.com>
From:   Vlastimil Babka <vbabka@suse.cz>
Message-ID: <f73cc1c6-2950-c56d-6a57-8cebb23db65b@suse.cz>
Date:   Wed, 5 May 2021 23:29:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <YJLk1tmDeGed58yr@carbon.dhcp.thefacebook.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/5/21 8:32 PM, Roman Gushchin wrote:
> On Wed, May 05, 2021 at 08:02:06PM +0200, Vlastimil Babka wrote:
>> On 5/5/21 7:30 PM, Roman Gushchin wrote:
>> > On Wed, May 05, 2021 at 11:46:13AM -0400, Waiman Long wrote:
>> >> 
>> >> With this change, all the objcg pointer array objects will come from
>> >> KMALLOC_NORMAL caches which won't have their objcg pointer arrays. So
>> >> both the recursive kfree() problem and non-freeable slab problem are
>> >> gone. Since both the KMALLOC_NORMAL and KMALLOC_CGROUP caches no longer
>> >> have mixed accounted and unaccounted objects, this will slightly reduce
>> >> the number of objcg pointer arrays that need to be allocated and save
>> >> a bit of memory.
>> > 
>> > Unfortunately the positive effect of this change will be likely
>> > reversed by a lower utilization due to a larger number of caches.
>> > 
>> > Btw, I wonder if we also need a change in the slab caches merging procedure?
>> > KMALLOC_NORMAL caches should not be merged with caches which can potentially
>> > include accounted objects.
>> 
>> Good point. But looks like kmalloc* caches are extempt from all merging in
>> create_boot_cache() via
>> 
>> 	s->refcount = -1;       /* Exempt from merging for now */
> 
> Wait, s->refcount is adjusted to 1 in create_kmalloc_cache() after calling
> into create_boot_cache?

Hmm I missed that

Now I wonder why all kmalloc caches on my system have 0 aliases :)
cat /sys/kernel/slab/kmalloc-*/aliases


> It means they are not exempt actually.
>