Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 26 Nov 2019 17:54:20 +0100
From:   Michal Hocko <mhocko@kernel.org>
To:     Christopher Lameter <cl@linux.com>
Cc:     LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: SLUB: purpose of sysfs events on cache creation/removal
Message-ID: <20191126165420.GL20912@dhcp22.suse.cz>
References: <20191126121901.GE20912@dhcp22.suse.cz>
 <alpine.DEB.2.21.1911261632030.9857@www.lameter.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.21.1911261632030.9857@www.lameter.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue 26-11-19 16:32:56, Cristopher Lameter wrote:
> On Tue, 26 Nov 2019, Michal Hocko wrote:
> 
> > Hi,
> > I have just learnt about KOBJ_{ADD,REMOVE} sysfs events triggered on
> > kmem cache creation/removal when SLUB is configured. This functionality
> > goes all the way down to initial SLUB merge. I do not see any references
> > in the Documentation explaining what those events are used for and
> > whether there are any real users.
> >
> > Could you shed some more light into this?
> 
> I have no idea about what this is.

It seems to be there since the initial merge. I suspect this is just
following a generic sysfs rule that each file has to provide those
events?

> There have been many people who
> reworked the sysfs support and this has been the cause for a lot of
> breakage over the years.

Remember any specifics?

I am mostly interested in potential users. In other words I am thinking
to suppress those events. There is already ke knob to control existence
of memcg caches but I do not see anything like this for root caches.
-- 
Michal Hocko
SUSE Labs