On Thu, Apr 07, 2022 at 07:55:11PM +0200, Alexander Bluhm wrote: > On Wed, Mar 23, 2022 at 06:13:27PM +0100, Alexander Bluhm wrote: > > In my opinion tracepoints give insight at minimal cost. It is worth > > it to have it in GENERIC to make it easy to use. > > After release I want to revive the btrace of refcounts discussion. > > As mpi@ mentioned the idea of dt(4) is to have these trace points > in GENERIC kernel. If you want to hunt a bug, just turn it on. > Refounting is a common place for bugs, leaks can be detected easily. > > The alternative are some defines that you can compile in and access > from ddb. This is more work and you would have to implement it for > every recount. > https://marc.info/?l=openbsd-tech&m=163786435916039&w=2 > > There is no measuarable performance difference. dt(4) is written > in a way that is is only one additional branch. At least my goal > is to add trace points to useful places when we identify them.
DT_INDEX_ENTER() still checks the index first, so it has two branches in practice. I think dt_tracing should be checked first so that it serves as a gateway to the trace code. Under normal operation, the check's outcome is always the same, which is easy even for simple branch predictors. I have a slight suspicion that dt(4) is now becoming a way to add code that would be otherwise unacceptable. Also, how "durable" are trace points perceived? Is an added trace point an achieved advantage that is difficult to remove even when its utility has diminished? There is a similarity to (ad hoc) debug printfs too.
