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 31458C433F5 for ; Thu, 10 Mar 2022 23:41:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F8B88D0002; Thu, 10 Mar 2022 18:41:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A7B78D0001; Thu, 10 Mar 2022 18:41:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3706A8D0002; Thu, 10 Mar 2022 18:41:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 28B0E8D0001 for ; Thu, 10 Mar 2022 18:41:04 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id EE57320619 for ; Thu, 10 Mar 2022 23:41:03 +0000 (UTC) X-FDA: 79230099606.11.F33016C Received: from out2.migadu.com (out2.migadu.com [188.165.223.204]) by imf12.hostedemail.com (Postfix) with ESMTP id 54E6C40013 for ; Thu, 10 Mar 2022 23:41:03 +0000 (UTC) Date: Thu, 10 Mar 2022 15:40:55 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1646955661; 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=QmZuyp8wzvSnPEzivEMgnaPm7ZNMcV3dkHxwoQBmJHU=; b=xLucBLdNJH1nrbhKMW1gts1Sy9978t+GtdhQeGbh+ms9Wly6EG0OpIetGCXCWG3gwQXa+v Z94nFcOu0ZRiu0OgAii4/eRs6zfWheh8q1SnG24iqq5U3jR5J8gOOhyt8a4SVdfk1A/dSR j3l6XXQuz2hsWr344ZTMAAsAMCURM0M= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Yosry Ahmed Cc: guro@fb.com, vvs@virtuozzo.com, Michal Hocko , Andrew Morton , Shakeel Butt , Johannes Weiner , cl@linux.com, linux-mm@kvack.org Subject: Re: Questions about memcg_slabinfo.py drgn script Message-ID: References: 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-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 54E6C40013 X-Stat-Signature: u7p9o8pb5cm7oac6bxg76d5zaj3rbj59 Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=xLucBLdN; spf=pass (imf12.hostedemail.com: domain of roman.gushchin@linux.dev designates 188.165.223.204 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-HE-Tag: 1646955663-809492 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 Thu, Mar 10, 2022 at 12:21:44PM -0800, Yosry Ahmed wrote: > Hi everyone, > > I was looking at the memcg_slabinfo.py drgn script that offers a > replacement to the deprecated memory.kmem.slabinfo. I had some > questions about how it collects the memcg slab stats: Hi Yosry! First, I have to admit that I haven't spent too much time optimizing this script for speed. So, there are almost certainly available opportunities to enhance it and patches are highly welcome. > > 1. Why does the script loop through all struct pages on the system? > Wouldn't it be more efficient to loop for every kmem_cache, for every > online kmem_cache_node, then loop through slabs_free, slabs_full, and > slabs_partial lists? It's somewhat tricky with SLUB because of per-cpu partial pages (I'm less familiar with SLAB). In theory, we have a single-linked list of such pages, but idk if we can reliably traverse it (given that it will be changed concurrently). We also will be way more dependent on SLUB internals. However it still might be a good optimization. > > This seems more consistent with how /proc/slabinfo works, and more > efficient. I tested this on SLAB using a crash script as I am unable > to run drgn on my current setup. I am not sure how correct this would > be for SLUB though. /proc/slabinfo has its own weaknesses, e.g. it shows systematically wrong numbers for slab utilization because of how it handles per-cpu partial pages (on SLUB). > > 2. Before looping through pages, why does the script collect all > objcgs belonging to the desired memcg in a set, and then test every > objcg in a slab page to see whether it belongs to that memcg. Wouldn't > it be easier to just check objcg->memcg? AFAICT this gets updated as > well when the objcg is reparented. I can't think of any good reason now, however it's not obviously faster (I guess dereferencing of a pointer in drgn can be more expensive than doing few "local" comparison, something to measure). If it is faster, it will be a good enhancement. > > Sorry for my ignorance if any of the assumptions I made are incorrect. > I just wanted to get more understanding of the implementation > decisions taken while writing the script. You're welcome!