On Wed, May 3, 2023 at 7:25 PM Tejun Heo <tj@xxxxxxxxxx> wrote: > > Hello, > > On Wed, May 03, 2023 at 01:14:57PM -0700, Suren Baghdasaryan wrote: > > On Wed, May 3, 2023 at 1:00 PM Tejun Heo <tj@xxxxxxxxxx> wrote: > > > Another related question. So, the reason for macro'ing stuff is needed is > > > because you want to print the line directly from kernel, right? > > > > The main reason is because we want to inject a code tag at the > > location of the call. If we have a code tag injected at every > > allocation call, then finding the allocation counter (code tag) to > > operate takes no time. > > > > > Is that > > > really necessary? Values from __builtin_return_address() can easily be > > > printed out as function+offset from kernel which already gives most of the > > > necessary information for triaging and mapping that back to source line from > > > userspace isn't difficult. Wouldn't using __builtin_return_address() make > > > the whole thing a lot simpler? > > > > If we do that we have to associate that address with the allocation > > counter at runtime on the first allocation and look it up on all > > following allocations. That introduces the overhead which we are > > trying to avoid by using macros. > > I see. I'm a bit skeptical about the performance angle given that the hot > path can be probably made really cheap even with lookups. In most cases, > it's just gonna be an extra pointer deref and a few more arithmetics. That > can show up in microbenchmarks but it's not gonna be much. The benefit of > going that route would be the tracking thing being mostly self contained. I'm in the process of rerunning the tests to compare the overhead on the latest kernel but I don't expect that to be cheap compared to kmalloc(). > > That said, it's nice to not have to worry about allocating tracking slots > and managing hash table, so no strong opinion. > > Thanks. > > -- > tejun > > -- > To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@xxxxxxxxxxx. >
