From owner-svn-src-head@freebsd.org Tue May 2 17:47:50 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25B2BD5B190; Tue, 2 May 2017 17:47:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id AE9561507; Tue, 2 May 2017 17:47:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c122-106-153-191.carlnfd1.nsw.optusnet.com.au [122.106.153.191]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id 85FD3D43E1A; Wed, 3 May 2017 03:47:41 +1000 (AEST) Date: Wed, 3 May 2017 03:47:37 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Konstantin Belousov cc: Bruce Evans , Alan Somers , Gleb Smirnoff , "src-committers@freebsd.org" , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: 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... In-Reply-To: <20170502170721.GI1622@kib.kiev.ua> Message-ID: <20170503032643.K2791@besplex.bde.org> References: <20170419130428.J956@besplex.bde.org> <20170430201324.GV1622@kib.kiev.ua> <20170501163725.U972@besplex.bde.org> <20170502095527.GB1622@kib.kiev.ua> <20170502203703.I1176@besplex.bde.org> <20170502121711.GE1622@kib.kiev.ua> <20170502223324.P1508@besplex.bde.org> <20170502144823.GH1622@kib.kiev.ua> <20170503005322.K1968@besplex.bde.org> <20170502170721.GI1622@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=KeqiiUQD c=1 sm=1 tr=0 a=Tj3pCpwHnMupdyZSltBt7Q==:117 a=Tj3pCpwHnMupdyZSltBt7Q==:17 a=kj9zAlcOel0A:10 a=rddVpAsjNRg6FjyyaoQA:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:47:50 -0000 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