[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250911143132.ca88948c48df874f71983218@linux-foundation.org>
Date: Thu, 11 Sep 2025 14:31:32 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Usama Arif <usamaarif642@...il.com>
Cc: Yueyang Pan <pyyjason@...il.com>, David Wang <00107082@....com>, Suren
Baghdasaryan <surenb@...gle.com>, kent.overstreet@...ux.dev,
vbabka@...e.cz, hannes@...xchg.org, rientjes@...gle.com,
roman.gushchin@...ux.dev, harry.yoo@...cle.com, shakeel.butt@...ux.dev,
pasha.tatashin@...een.com, souravpanda@...gle.com, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] alloc_tag: mark inaccurate allocation counters in
/proc/allocinfo output
On Thu, 11 Sep 2025 12:00:23 -0400 Usama Arif <usamaarif642@...il.com> wrote:
> > I think simply adding * to the end of function name or filename is sufficient
> > as they are already str.
> >
>
> Instead of:
>
> 49152* 48* arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create
>
> Could we do something like:
>
> 49152 48 arch/x86/kernel/cpu/mce/core.c:2709 func:mce_device_create(inaccurate)
Can we add another row, saying "the previous row was inaccurate"? I
guess that would break parsers also.
I don't know if this was by design, but the present format does provide
extensibility. It is basically
NNNN NNN name:value name:value
one could arguably append a third name:value and hope that authors of
existing parsers figured this out.
Whatev. I'll drop this version from mm.git.
Powered by blists - more mailing lists