NetBSD Problem Report #57231

From www@netbsd.org  Tue Feb 14 15:52:25 2023
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 2BE0A1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 14 Feb 2023 15:52:25 +0000 (UTC)
Message-Id: <20230214155223.A4D391A923A@mollari.NetBSD.org>
Date: Tue, 14 Feb 2023 15:52:23 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: event counters aren't dtraceable
X-Send-Pr-Version: www-1.0

>Number:         57231
>Category:       kern
>Synopsis:       event counters aren't dtraceable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 14 15:55:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
The NetBSD Countation
>Environment:
creeping up in temperature
>Description:
The evcnt(9) API is designed for users to manually update the ev_count member of a struct evcnt object.  The caller is responsible for serializing access, whether with CPU-local data, atomics, or locks.  For example:

arch/aarch64/aarch64/fpu.c:             curcpu()->ci_vfp_use.ev_count++;
arch/arm/cortex/pl310.c:        atomic_inc_64(&arml2cc_sc->sc_ev_inv.ev_count);

The NetBSD kernel has multitudes of event counters.  For example, my laptop has 273 event counters.

These events can be read with `vmstat -e', but it would be useful if we could use them as dtrace probes, for example to get a histogram of stack traces for when the events happen.

Perhaps we could define an ev_count(&evcnt) function which (a) has a static dtrace probe, and (b) returns a pointer to the ev_count member for the caller to increment with ++ or atomic_inc_64 or whatever (perhaps with attribute((warn_unused_result)) to catch the mistake of a missing increment).

That way, the above examples could be written:

	(*ev_count(&curcpu()->ci_vfp_use))++;
	atomic_inc_64(ev_count(&arml2cc_sc->sc_ev_inv));

And maybe add an ev_count_inc function to make the non-atomic case a little less of a mouthful:

	ev_count_inc(&curcpu()->ci_vfp_use);
>How-To-Repeat:
dtraaaaaaaaaaaaaaaaaaace
>Fix:
Yes please!

Home	PR Database Search