On Wed, Feb 14, 2024 at 8:55 AM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Tue, 13 Feb 2024 14:59:11 -0800 Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>
> > > > If you think you can easily achieve what Michal requested without all that,
> > > > good.
> > >
> > > He requested something?
> >
> > Yes, a cleaner instrumentation. Unfortunately the cleanest one is not
> > possible until the compiler feature is developed and deployed. And it
> > still would require changes to the headers, so don't think it's worth
> > delaying the feature for years.
>
> Can we please be told much more about this compiler feature?
> Description of what it is, what it does, how it will affect this kernel
> feature, etc.
Sure. The compiler support will be in a form of a new __attribute__,
simplified example:
// generate data for the wrapper
static void _alloc_tag()
{
static struct alloc_tag _alloc_tag __section ("alloc_tags")
= { .ct = CODE_TAG_INIT, .counter = 0 };
}
static inline int
wrapper (const char *name, int x, int (*callee) (const char *, int),
struct alloc_tag *callsite_data)
{
callsite_data->counter++;
printf ("Call #%d from %s:%d (%s)\n", callsite_data->counter,
callsite_data->ct.filename, callsite_data->ct.lineno,
callsite_data->ct.function);
int ret = callee (name, x);
printf ("Returned: %d\n", ret);
return ret;
}
__attribute__((annotate("callsite_wrapped_by", wrapper, _alloc_tag)))
int foo(const char* name, int x);
int foo(const char* name, int x) {
printf ("Hello %s, %d!\n", name, x);
return x;
}
Which we will be able to attach to a function without changing its
name and preserving the namespace (it applies only to functions with
that name, not everything else).
Note that we will still need _noprof versions of the allocators.
>
> Who is developing it and when can we expect it to become available?
Aleksei Vetrov (google) with the help of Nick Desaulniers (google).
Both are CC'ed on this email.
After several iterations Aleksei has a POC which we are evaluating
(https://github.com/llvm/llvm-project/compare/main...noxwell:llvm-project:callsite-wrapper-tree-transform).
Once it's in good shape we are going to engage with CLANG and GCC
community to get it upstreamed. When it will become available and when
the distributions will pick it up is anybody's guess. Upstreaming is
usually a lengthy process.
>
> Will we be able to migrate to it without back-compatibility concerns?
> (I think "you need quite recent gcc for memory profiling" is
> reasonable).
The migration should be quite straight-forward, replacing the macros
with functions with that attribute.
>
>
> Because: if the maintainability issues which Michel describes will be
> significantly addressed with the gcc support then we're kinda reviewing
> the wrong patchset. Yes, it may be a maintenance burden initially, but
> at some (yet to be revealed) time in the future, this will be addressed
> with the gcc support?
That's what I'm aiming for. I just don't want this placed on hold
until the compiler support is widely available, which might take
years.
>
