ruxreset: Add an inline function to reset all the stats in rusage_ext

[jhb]

Summary

Use it in proc0_post to reset per-process CPU usage.

Suggested by: olce

[olce]

sys/sys/proc.h

1329–1340

Maybe bzero()? Half joking.

1330

_locked prefix for consistency with other rux*_locked() functions?

1330

(well, suffix)

[jhb]

sys/sys/proc.h

1329–1340

The compiler should be doing that already in effect (and I believe we prefer memset() to bzero() for new code).

1330

So normally we use _locked when there is an existing routine that wraps it that takes the lock. We also tend to assert the relevant lock is held in *_locked functions. Neither of those are true in this case. I would argue that ruxagg_ext_locked() is misnamed and should just be ruxagg_ext(). There are many functions that require a lock or reference of some sort to held by the caller that don't use a _locked suffix (e.g. pfind(), all the fo_* operations on file descriptors, etc.)

[olce]

sys/sys/proc.h

1329–1340

Yes, but here again, that's not for performance but rather a defensive measure towards someone adding a new field to struct rusage_ext and forgetting to update this function.

Why would we prefer memset() to bzero()? The latter has value for a very common case, avoids the error of inverting value and size in memset() (we might get a warning on 64-bit platforms in this case?), and has no drawbacks that I can see. We are not tied by any POSIX removal except for symbol visibility for applications, and that's kernel code here anyway.

1330

Fine.

[jhb]

sys/sys/proc.h

1329–1340

Re: memset vs bzero: bzero is a pre-POSIX BSDism whereas memset() is standardized.

[olce]

sys/sys/proc.h

1329–1340

Yes. bzero() was even in POSIX for a while. POSIX, during deprecation, recommended implementing bzero() as a macro over memset(). With the elements I have seen so far (POSIX, Internet at large), deprecation of bzero() seems to have been a mistake essentially.

But all this really matters only to applications, and has no real bearing in the kernel. Also, we have explicit_bzero(), and no explicit_memset() (although that would be easy to add).

[olce]

sys/sys/proc.h

1329–1340

Oh, for the record, we have in fact memset_explicit() in libc (but not in the kernel it seems), which appears in the C23 standard (it is not in C17).

[kib]

sys/sys/proc.h

1329–1340

Argument pro use of bzero() is that this is what bde@ strongly preferred, since it was historic in BSD kernels.

Argument pro use of memset() is that despite our kernel is freestanding environment, we expand memset() into __builtin_memset(), which informs the gcc-compatible compiler about the semantic of the call, allowing several optimizations. At very least, the call if often inlined, at least on x86.

After writing this, I reminded that our bzero() is also expanded to __builtin_memset(..., 0, ...);

[olce]

sys/sys/proc.h

1329–1340

After writing this, I reminded that our bzero() is also expanded to __builtin_memset(..., 0, ...);

Yes, was aware, and performance-wise it's identical. But really the point for me here is not performance, but intelligibility, and reduced chances of errors.