Date: Wed, 16 Mar 2016 12:39:48 +0800 From: Julian Elischer <julian@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org>, Ravi Pokala <rpokala@mac.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r296880 - in head: share/man/man9 sys/kern sys/sys Message-ID: <56E8E394.7090100@freebsd.org> In-Reply-To: <20160315191229.GU1328@FreeBSD.org> References: <201603150005.u2F050ps086390@repo.freebsd.org> <BBC31E16-31C0-426A-96C0-1393CA3DC379@panasas.com> <20160315191229.GU1328@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/03/2016 3:12 AM, Gleb Smirnoff wrote: > Ravi, > > On Mon, Mar 14, 2016 at 05:33:06PM -0700, Ravi Pokala wrote: > R> To make sure I'm reading this correctly: > R> > R> (1) The sysctl operates on an opaque array of (uint64_t)s. The elements of the array are not individually accessible. > > On array of counter_u64_t. The elements are individually accessible of course, > but not by this sysctl API. > > R> (2) Reading the sysctl populates each element of the userspace array by calling counter_u64_fetch() on the corresponding element of the kernelspace array. > > Right. > > R> (3) Writing the sysctl clears the kernelspace array by calling counter_u64_zero() on each element. > > Right. > but it is not atomic. since the user process decides the time delay between a read and write (zero) there could be a lot of missed counts if you are resetting to zero after each read. better to just read in a loop and not zero.. here are somethings I've wanted at various times: read/zero atomic read timestamp as part of imported struct. (because you really can't do accurate timing from user space, but knowing when the data was read is a good replacement). read a "mib" (for want of a better term) for each set, giving individual field names.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56E8E394.7090100>