svn commit: r317061 - in head: libexec/rpc.rstatd sys/amd64/amd64 sys/amd64/include sys/arm/arm sys/arm/include sys/arm64/include sys/cddl/contrib/opensolaris/uts/common/fs/zfs sys/compat/linprocfs...

[Bruce Evans]

On Tue, 2 May 2017, Konstantin Belousov wrote:

> On Wed, May 03, 2017 at 01:31:10AM +1000, Bruce Evans wrote:
>>
>>
>> On Tue, 2 May 2017, Konstantin Belousov wrote:
>> I also thought of changing the scale when the values get high.  The values
>> would increase slower above about 2G instead of stabilizing at 4G-1.
>> This is basically floating point and too complicated since nothing would
>> understand it.
>>
>> Which counters wrap faster than a reasonable refresh interval of 1-10
>> seconds (which should be shorter if wrapping is a problem)?
> Things like various counters for pages freed due to a reason can.  E.g.
> freed due to the process exit is the counter which I saw changing fast.

4 billion page operations/second or 10 is impossible. It is difficult
to even increment a register to count events that fast.

> Wire counts might fluctuate relatively quickly, but I think that wiring
> is slower.  Unwiring might be fast.

The need to zero pages before reuse limits the speed.

>> I just noticed that this sysctl is r/o (I thought I was preserving support
>> for resetting 64-bit counters using a 32-bit size in my fix in
>> sysctl_handle_counter_64().  That function has the dubious feature of not
>> checking the size, so it allows writes of any length (0 to SIZE_MAX,
>> possibly larger than the user data) to reset the counter to zero.)
>>
>> The r/o misfeature goes back to at least FreeBSD-3.  64-bit counters need
>> resetting less than 32-bit ones, and it is more useful to ever reset them
>> since they can hold the full counts since boot time, but there is no reason
>> to limit resetting them now that the low-level code supports it.  Is there
>> already a better atomic reset of all vm stats?
>
> I do not see why vmstat counters ever need to be reset.  I do not think
> that truncating the value to present small values to 32bit readers is
> a reasonable cause.

It would be mostly for presenting a consistent set of values.

> diff --git a/sys/vm/vm_meter.c b/sys/vm/vm_meter.c
> index 5f4cd46ab1e..b4666a400b2 100644
> --- a/sys/vm/vm_meter.c
> +++ b/sys/vm/vm_meter.c
> @@ -266,8 +266,27 @@ static SYSCTL_NODE(_vm_stats, OID_AUTO, vm, CTLFLAG_RW, 0,
> 	"VM meter vm stats");
> SYSCTL_NODE(_vm_stats, OID_AUTO, misc, CTLFLAG_RW, 0, "VM meter misc stats");
>
> +static int
> +sysctl_handle_vmstat(SYSCTL_HANDLER_ARGS)
> +{
> +	uint64_t val;
> +#ifdef COMPAT_FREEBSD11
> +	uint32_t val32;
> +#endif
> +
> +	val = counter_u64_fetch(*(counter_u64_t *)arg1);
> +#ifdef COMPAT_FREEBSD11
> +	if (req->oldlen == sizeof(val32)) {
> +		val32 = val;		/* truncate */
> +		return (SYSCTL_OUT(req, &val32, sizeof(val32)));
> +	}
> +#endif
> +	return (SYSCTL_OUT(req, &val, sizeof(val)));
> +}
> +
> #define	VM_STATS(parent, var, descr) \
> -    SYSCTL_COUNTER_U64(parent, OID_AUTO, var, CTLFLAG_RD, &vm_cnt.var, descr)
> +    SYSCTL_OID(parent, OID_AUTO, var, CTLTYPE_U64 | CTLFLAG_MPSAFE | \
> +    CTLFLAG_RD, &vm_cnt.var, 0, sysctl_handle_vmstat, "QU", descr);
> #define	VM_STATS_VM(var, descr)		VM_STATS(_vm_stats_vm, var, descr)
> #define	VM_STATS_SYS(var, descr)	VM_STATS(_vm_stats_sys, var, descr)

OK.

Bruce