From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD03DC433F5 for ; Mon, 18 Apr 2022 17:27:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F1BF8D001B; Mon, 18 Apr 2022 13:27:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A0E58D001A; Mon, 18 Apr 2022 13:27:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 269D78D001B; Mon, 18 Apr 2022 13:27:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 1952F8D001A for ; Mon, 18 Apr 2022 13:27:44 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id D8C051207FC for ; Mon, 18 Apr 2022 17:27:43 +0000 (UTC) X-FDA: 79370682006.20.4F37F89 Received: from out1.migadu.com (out1.migadu.com [91.121.223.63]) by imf15.hostedemail.com (Postfix) with ESMTP id 4DC63A000E for ; Mon, 18 Apr 2022 17:27:43 +0000 (UTC) Date: Mon, 18 Apr 2022 10:27:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1650302861; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/Gp18eUoW03iuPGj3GLuowLyhOcAU8RggWp55xHDiug=; b=YOzUkpmXwDTK8OBKTvkVHeeh6b7M8TfcYAqpT4+k8uxZSRvkpWNPd8elMnjNOnEu8sybek jMTg6/6gOLCJ4jwFUQH8mO1SdLzlSVd0Jm7mPmTmxQw25N+e+Q+Mw2G3IDzdKktQmrWwCX GldI0fnvHg6eAaQAO9QGWaWfv70VUnk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , Dave Chinner , linux-kernel@vger.kernel.org, Johannes Weiner , Michal Hocko , Shakeel Butt , Yang Shi Subject: Re: [PATCH rfc 0/5] mm: introduce shrinker sysfs interface Message-ID: References: <20220416002756.4087977-1-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 4DC63A000E X-Rspam-User: Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=YOzUkpmX; spf=pass (imf15.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.121.223.63 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Stat-Signature: sq1zpphnx9ejdsufnhkamyixj1jaimmw X-HE-Tag: 1650302863-831603 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Apr 18, 2022 at 12:27:36PM +0300, Mike Rapoport wrote: > On Fri, Apr 15, 2022 at 05:27:51PM -0700, Roman Gushchin wrote: > > There are 50+ different shrinkers in the kernel, many with their own bells and > > whistles. Under the memory pressure the kernel applies some pressure on each of > > them in the order of which they were created/registered in the system. Some > > of them can contain only few objects, some can be quite large. Some can be > > effective at reclaiming memory, some not. > > > > The only existing debugging mechanism is a couple of tracepoints in > > do_shrink_slab(): mm_shrink_slab_start and mm_shrink_slab_end. They aren't > > covering everything though: shrinkers which report 0 objects will never show up, > > there is no support for memcg-aware shrinkers. Shrinkers are identified by their > > scan function, which is not always enough (e.g. hard to guess which super > > block's shrinker it is having only "super_cache_scan"). They are a passive > > mechanism: there is no way to call into counting and scanning of an individual > > shrinker and profile it. > > > > To provide a better visibility and debug options for memory shrinkers > > this patchset introduces a /sys/kernel/shrinker interface, to some extent > > similar to /sys/kernel/slab. > > Wouldn't debugfs better fit the purpose of shrinker debugging? I think sysfs fits better, but not a very strong opinion. Even though the interface is likely not very useful for the general public, big cloud instances might wanna enable it to gather statistics (and it's certainly what we gonna do at Facebook) and to provide additional data when something is off. They might not have debugfs mounted. And it's really similar to /sys/kernel/slab. Are there any reasons why debugfs is preferable? Thanks!