From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta0.migadu.com (out-132.mta0.migadu.com [91.218.175.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78BD245040A for ; Thu, 24 Sep 2026 09:52:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790243580; cv=none; b=sUdBQc1M12xKa0Piva0zWKoAXFuH693C0+mJYiKBHtcKJdezIudPBGHOHOKn8CWjslql4xcq29ipXXKt/7U22zjPdEGvfiYpiFZ4bH5QwlgAvrx9hwXlJZF8OspPePV+rMxAzGXPMLDGtTHhsfsSf3SSPz9D6CRD4pT8WtiTiBU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790243580; c=relaxed/simple; bh=CACgk1em+Vy8Gh1bLJdug8Dy1sGNAy+1bOJLeSRf7IU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=l5oLbG4gM40fNkTHk0fnfC6HiUEH+A4niWryOBn3WyJRt9d5M64P4hUT7v+v8b24eB/Ta58xlE0CahK2aZDD0APJKIPKy+sEZuvIFE+pIlcquS6AUjb8naOAYU7/8frrf17A/teIfvPBVI84tBHC/+R2Yh9xIKRvnGRagRjq17o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=v+yfmRxo; arc=none smtp.client-ip=91.218.175.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="v+yfmRxo" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=CACgk1em+Vy8Gh1bLJdug8Dy1sGNAy+1bOJLeSRf7IU=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790243542; v=1; x=1790848342; b=v+yfmRxoiCZYw0BX/hk9KDD8VZSGbzrq1Zazi/MgI2IRvjP8/xr69rKJLi5gUbimeabIicDX KjwI1XZz8RPD1kiYG/1ke+Gnjv0ijR/4/1UZYgcybhbqu3cXe3y2IjeN4SfGEWL2lyxr3NgGFTl lwqycXdp9Bs7ZwK2oDeCEk7k= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id c0029a296d3c7a22; Thu, 24 Sep 2026 09:52:22 +0000 X-Mizu-Trace-ID: c0029a296d3c7a22 X-Migadu-Flow: FLOW_OUT Message-ID: <057359f7-0e8f-416b-8b5e-0b60c1c936e9@linux.dev> Date: Thu, 24 Sep 2026 17:53:25 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] alloc_tag: Introduce selective tracing for MAP To: Abhishek Bapat Cc: Steven Rostedt , Masami Hiramatsu , Mathieu Desnoyers , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org, Shuah Khan , Suren Baghdasaryan , Andrew Morton References: Content-Language: en-US From: Hao Ge In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Abhishek Thanks for your patch. On 2026/9/22 05:26, Abhishek Bapat wrote: > The existing memory allocation profiling (MAP) tool accurately maintains > aggregate counters for overall memory accounting. However, relying > purely on aggregated counters restrics the visibility needed for > targeted debugging. > > This patch series integrates three new tracepoints (alloc_tag_hit, > alloc_tag_mem_alloced and alloc_tag_mem_freed) directly into the > alloc_hooks_tag fast path. > > Enabling trace events globally for all allocations introduces a severe > baseline overhead. To limit the performance overhead, we let the admin > select specific allocations to be traced. > > A new IOCTL is introduced to allow privileged users to determine which > allocation tags need tracing enabled. The IOCTL utilizes the > pre-existing filtering mechanism to specify the allocation tags to > enable tracing on. > I think this cover‑letter could go into more detail. Also, the cover‑letter doesn't include any how‑to‑use. Looking over this series, it seems you expect users to first call ALLOCINFO_IOC_GET_AT to obtain a tag, then pass that tag into ALLOCINFO_IOC_TOGGLE_TRACE. This behaviour is not reflected in the existing cover‑letter. Before reading the code, I assumed I could just pass a module name to trace all allocations from that module. After going through the implementation, that turns out not to be the case. Because patch 2 enforces a full mask requirement for the filter. struct allocinfo_filter filter = { .mask = ALLOCINFO_FILTER_MASK_MODNAME | ALLOCINFO_FILTER_MASK_FUNCTION | ALLOCINFO_FILTER_MASK_FILENAME | ALLOCINFO_FILTER_MASK_LINENO, .fields = params.fields, }; So to trace all allocations from an entire module, users have to combine ALLOCINFO_IOC_GET_AT, ALLOCINFO_IOC_GET_NEXT and ALLOCINFO_IOC_TOGGLE_TRACE together. I have no strong objections if this is the intended design. That said, we should settle on the expected usage model up‑front. Having corresponding Documentation would also be quite helpful. That way when others ask how to work with this feature, we can point them to existing written material. https://elixir.bootlin.com/linux/v7.3-rc3/source/Documentation/mm/allocation-profiling.rst Thanks Best Regards Hao > Abhishek Bapat (4): > alloc_tag: Add trace events for tracing allocations > alloc_tag: Introduce IOCTLs to toggle allocation tracepoints > alloc_tag: extend allocinfo_filter to support tracing queries > alloc_tag: add a test for trace state toggle and filtering > > MAINTAINERS | 1 + > include/linux/alloc_tag.h | 94 +++++++++--- > include/linux/codetag.h | 5 +- > include/trace/events/alloc_tag.h | 122 +++++++++++++++ > include/uapi/linux/alloc_tag.h | 17 ++- > mm/alloc_tag.c | 142 +++++++++++++++++- > .../alloc_tag/allocinfo_ioctl_test.c | 111 +++++++++++++- > 7 files changed, 462 insertions(+), 30 deletions(-) > create mode 100644 include/trace/events/alloc_tag.h > > > base-commit: 8d61431ed2607386b427752505379536eb634ce8