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 C91F7E668AB for ; Sun, 24 Nov 2024 13:39:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AC1B6B0085; Sun, 24 Nov 2024 08:39:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 15C066B0088; Sun, 24 Nov 2024 08:39:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 049586B0089; Sun, 24 Nov 2024 08:38:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D9E996B0085 for ; Sun, 24 Nov 2024 08:38:59 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5887C140384 for ; Sun, 24 Nov 2024 13:38:59 +0000 (UTC) X-FDA: 82821094314.22.D6D7653 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf28.hostedemail.com (Postfix) with ESMTP id 29A05C0007 for ; Sun, 24 Nov 2024 13:38:53 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of "SRS0=0+Et=ST=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=0+Et=ST=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732455536; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/y7ccuNg/OQpMvBik8MHbKT8d9WARQUsCfGWps1n+XI=; b=3ZkuORKTEZ41izYoVY2PZoFq/ABE8Ye8cJuu614dNkVCofWeUSO/krLbSrlrM5SicbleQv 4lAw6wNGTtTOQMHsUGAJeRjy2iLHSPa56ugjqvZ9gknMKz6xAqlDhfCPjn5Euv2bvfLZCg 2YPgllQfT+tNbKt4NfjQHZZHNgiqv+A= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of "SRS0=0+Et=ST=goodmis.org=rostedt@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=0+Et=ST=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732455536; a=rsa-sha256; cv=none; b=saWrSdpiZGqnfqq6x++aKW5Nh0ixtlnlSRdYKkaT4CK1N336AhEpQMCFRLIeJVREK9Qc8F Skn7o+sBHx2/SyVuWC+ZEqNkEagQUX61eOLInueSYHmwsrIlvf5Q+GZSCshwgQZLoB3qKI 5sS+9gdKRLb2cqZ/m/JgHZ/EnX5wjAs= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 0C30A5C561A; Sun, 24 Nov 2024 13:38:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8EB8C4CECC; Sun, 24 Nov 2024 13:38:54 +0000 (UTC) Date: Sun, 24 Nov 2024 08:39:39 -0500 From: Steven Rostedt To: Vlastimil Babka Cc: Shakeel Butt , Matthew Wilcox , Andrew Morton , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , Axel Rasmussen , Suren Baghdasaryan , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Meta kernel team Subject: Re: [PATCH] mm: mmap_lock: optimize mmap_lock tracepoints Message-ID: <20241124083939.1fab4656@gandalf.local.home> In-Reply-To: References: <20241123060939.169978-1-shakeel.butt@linux.dev> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 29A05C0007 X-Stat-Signature: h8hf59fbdh3seqehyi6k75f7qufprpqf X-HE-Tag: 1732455533-548771 X-HE-Meta: U2FsdGVkX18aS1Tfztbu8OOSAraukeSVcknzeR0MEaC9bE/zmQ4oCcuPPBI9SNsez+Fedra6SYJZUXSEtcrt/hPL5dQfO56syu5X+ryK7oategftQ74thrMG1hv6cabwD11lsx+54+3vutizQggqfndphLpNmWEIA2jJlBwf7KJk/Rwkn4IbCkKdHnVJj/n+p0ly8EOGwULDunVYLHMLUQfy9FyzQZprE/a3lm7KpvqEjSJarD50boc5P+9N02GPF9CeotpbdpCB2OrKrioyebFTdHxG0xUlDyYXog8x3myvs2qfjFhTx7v4PAXOJpP9r0sCpMAm6TQskRl8Xe++ZydyWZfk21iUqn6iZOHxcAmPx2/04fimVlnGi2tktiOuWrlq4LIx4ToXt5KWfgYh6Fq3qWnqR6Tzztj2Zgp2XWg36S8hphPUAQYOy4GIeB1aI8FB6RNdoG5HbkPPVazm04kXNvUj0I2drHyz2a+BNJWTFATXp2znT1BkSec/9AhojbWvfn0cSkT2DbVJT9ByZUpFvLlrVS2Yw68YaAMn6sLy2etJM1ekzr8WlyDccPA/AiMUJSrd4kV3/Egj1FiP3nwXxpM5ovS+fCeTvVswkfn0JJZiVpNO8WJqkyDUDBRTktsr9aQPRfv0yCgIelfk+7EuwUZSvThoOZnRP9zmzSBpVntd0nzOXNy9u8tjyNh2R9YS8ibtJaxOrTqi56XBoa2EnKC5cxovhmPpDleE5bjR6aNdOAu6YjbBuxDdxd7aZqrtqx1xJLbpFMLJVMXxB2bLYdCEsLx1K75kMP0pY1/GGG46d3Ox7V+XspChUflePjOdwruY0aUvvll55YB6DCK1i2uiFjQQnB/+G7xGkUhnBBWjgN/ecWEH6xqj3nTm5ivrl2ybK1adWDQ1VnGsDYV39YvooLg/Vm6qJ5Yus8rzFIptGAMkWloDFo6hEdFFYTr2z6L5wbipg+2sJgB aZOS0WyN /pw+BbWNaUPZIdYttUVy/CLY330VYjVChZ9P5H36Cx7KmZaGBuUlrfC6Gaeuqm12ig1doqa+8zRgc6j0QfryPMP6nOklhw5Bhk4K+DAE7myUEa/lDTv7JD0uN7GefyIlNLp7QzEUnCPKXwnf52JRdi58SkU+Q4emoxTkW5ljKDB7J6fdN6A/kKk4GOLa9nf98/ppHADzs6uLhBuwpQgEVEtBbHdOxHtjmifxZTAYLhLqO8hSH/hAGS4/x9e4uiWMxXlIkXHtnfSKSMw2Agy9EZARUmGre29sFcze9Bdg7zaZNk0Q= 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: List-Subscribe: List-Unsubscribe: On Sat, 23 Nov 2024 22:38:59 +0100 Vlastimil Babka wrote: > On 11/23/24 22:35, Shakeel Butt wrote: > > On Sat, Nov 23, 2024 at 05:01:57PM +0000, Matthew Wilcox wrote: > >> On Fri, Nov 22, 2024 at 10:09:39PM -0800, Shakeel Butt wrote: > >> > TP_printk( > >> > - "mm=%p memcg_path=%s write=%s", > >> > - __entry->mm, > >> > - __get_str(memcg_path), > >> > + "mm=%p memcg_id=%llu write=%s", > >> > + __entry->mm, __entry->memcg_id, > >> > __entry->write ? "true" : "false" > >> > >> Is it actually useful to print out the (hashed) pointer of the mm? > >> Wouldn't the PID be more useful so you could actually associate it with > >> a task? > >> > > > > For our usecase i.e. bpftrace, we don't really care about these prints > > as we can directly access the arguments like mm in bpftrace. I wonder if > > others are using this hased pointer in some other way. I don't mind > > chaning it but I think that would be a separate patch. > > I wonder if it's actually hashed when trace events are obtained in binary > form, i.e. via trace-cmd. Might be hashed only when doing e.g. cat > trace_pipe as that's when the kernel's printk with its hashing is used? > > I guess that would be another argument for not using it in the tracepoint, > as it would be a sidechannel... This is no more a sidechannel than /proc/kallsyms. It is only accessible via the privileged users. It's very common and useful to show pointers in trace events. You can use eprobes to get information off of pointers too: echo 'e:mmap_lock_count mmap_lock/mmap_lock_start_locking count=+0($mm):u32' > /sys/kernel/tracing/dynamic_events and now you have an event that shows the mm_count of the mm structure. -- Steve