From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-170.mta1.migadu.com (out-170.mta1.migadu.com [95.215.58.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8DCA333737 for ; Tue, 6 Jan 2026 10:54:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767696894; cv=none; b=HQpO4QDmoTqAna+VFxSLvRVm07pnZY0QGX9i56AbEcJ6xPqtxFqIibLHSK+YLsa2Qwub4nuwdZDvC3BLJJzbAqajtWOTLqfqVA2hu19e50Lkk1iDvH1ReEg7fZCiN58PU9vX8od5XsgRL8I6i53+GiGWH7wKTULJLQW72mel0v4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767696894; c=relaxed/simple; bh=K2fxT4zj3WH3gouXft7P3HH5kGfOsO8RjoeVwKRA73Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bnv83tRc6hX4K2qHhw1Z4OpwPplhocalE+ayQjFUsKp+q6EgQkbLuZ5UiRAKerqgkH2GrX6wF+PKdn30jVdnB76P4rDD+3kspt7CxGchzjJjQj2HI1Agfk9Arhjklk/QY7uyHConlgYAF82pCnFVJB0OMse3jYCebZWyv+afpuA= 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=KXYD8d5A; arc=none smtp.client-ip=95.215.58.170 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="KXYD8d5A" Date: Tue, 6 Jan 2026 05:54:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1767696888; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=S72Lgbey/fnLxmYDS/ZNU+VaP8hmZ5dNjW9LwfYzt9s=; b=KXYD8d5ASOCoB2+ssLURRgJS/qHndWyXHRiK+0xHv/vfYrUK8Ekp+9rGfR8DoYqczIqSVs PIzvqLOSaU5PShe6FWogeoHe3bdeqdsky2hi3j5g5DBxhjohZgh4AmfbBmGjsSFNd7WGhI KMjHmONM6bOeuG/e4HZwv17Y3+CggdA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: David Wang <00107082@163.com> Cc: Suren Baghdasaryan , akpm@linux-foundation.org, hannes@cmpxchg.org, pasha.tatashin@soleen.com, souravpanda@google.com, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC] alloc_tag: add option to pick the first codetag along callchain Message-ID: References: <20251216064349.74501-1-00107082@163.com> <75285cc4.3c52.19b916d9490.Coremail.00107082@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <75285cc4.3c52.19b916d9490.Coremail.00107082@163.com> X-Migadu-Flow: FLOW_OUT On Tue, Jan 06, 2026 at 11:50:36AM +0800, David Wang wrote: > At 2026-01-06 05:12:48, "Suren Baghdasaryan" wrote: > >On Mon, Dec 15, 2025 at 10:44 PM David Wang <00107082@163.com> wrote: > >> > >> When tracking memory allocation for some specific function, > >> picking the first codetag is more desired, because there > >> is no need to track down all allocation sites in the call > >> graph and change them to _noprof version, which is quite > >> inflexible when the call graph is complex. > >> > >> For example, consider a simple graph: > >> > >> A ---> B ---> C ===> D > >> E ---> C > >> > >> ===> means a call with codetag > >> ---> means a call without codetag > >> > >> To profiling memory allocation for A, the call graph needs > >> to be changed to > >> A ===> B ---> C ---> D > >> E ===> C > >> Three call sites needs to be changed. > >> > >> But if pick the first codetag, only one change is needed. > >> A ===> B ---> C ===> D > >> E ---> C > >> > >> The drawback is some accounting for C is splited to A, > >> making the number not accurate for C. (But the overall > >> accounting is still the same.) > >> > >> This is useful when debug memory problems, not meant for > >> production usage though. > > > >Hi David, > >Sorry for the delay. Do you have specific examples when allocation > >needs to be accounted at the highest level > Hi, > > I do not have a very convincing practical example yet. :( > I started to think about this in this thread[1], debugging possible memory leak in cephfs. > If modules want to account its memory usage, they can plant codetags in their codepath > without worrying about codetags deeper in the code chain. > > And I noticed that some callsites' memory usage is incomplete, because its accounting > is split by codetags deeper in the code chain > For example, on my system, I have > 512 1 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init > but if pick first codetag, I would have > 20992 10 drivers/usb/core/hub.c:6080 [usbcore] func:usb_hub_init > > One call chain > usb_hub_init==>alloc_workqueue--->__alloc_workqueue -->alloc_node_nr_active==>kzalloc_node > has two codetags, and its memory is not accounted to usb drivers. > > If interested in module's memory usage, picking the first codetag would be preferred, I guess. Is an end user going to be able to do anything with such an option? Your option just flattens the accounting - this results in incorrect accounting, not just insufficiently fine grained - and incorrect in a way that's harder to notice and find and fix. How many times have you gone down the wrong rabbit hole because your tools were subtly lying to you? This is something we really want to avoid. The fact that you have to be explicit about where the accounting happens via _noprof is a feature, not a bug :)