Date: Sun, 17 Mar 2013 21:26:34 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-projects@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r248438 - projects/counters/share/man/man9 Message-ID: <20130317192634.GW3794@kib.kiev.ua> In-Reply-To: <201303171912.r2HJC1nF016954@svn.freebsd.org> References: <201303171912.r2HJC1nF016954@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0uNolHhSuKIW4i3A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 07:12:01PM +0000, Gleb Smirnoff wrote: > Author: glebius > Date: Sun Mar 17 19:12:01 2013 > New Revision: 248438 > URL: http://svnweb.freebsd.org/changeset/base/248438 >=20 > Log: > Document counter(9). > +However, > +.Nm > +does not imply any > +.Xr locking 9 , > +neither any > +.Xr atomic 9 > +operations, thus are expected to be fast. I am unsure what do you mean there. E.g., the current i386 operation uses atomic(9) (not in the form of the code borrowed from atomic(9), but a locked instruction). I have intent to do the same for powerpc. > +API doesn't guarantee any protection from underflow. I suggest to not use term API when describing kernel programming interface. > +See > +.Sx IMPLEMENTATION DETAILS . > +.It Fn counter_u64_fetch cnt > +Obtain current snapshot of the data collected in > +.Nm > +.Fa cnt . > +The data obtained isn't guaranteed to be precise. Again, I am not sure what does the sentence mean. Without external synchronization, the returned value is invalid/obsoleted immediately, as usual, and it does not deserve a separate note. What could be more important for the caller, is that the returned sum might not reflect any real cumulative value for any moment. But the differences should be tiny. > +On all architectures > +.Nm > +is implemented using per-CPU data fields, that are specially aligned in > +memory, to avoid excessive CPU cache invalidation during updates. I would say 'to avoid unneeded inter-cpu bus traffic due to shared use of the variables between CPUs'. > +These are allocated using > +.Va UMA_ZONE_PCPU > +.Xr uma 9 > +zone. > +Update operation touches only the field that is private to current CPU. 'and which lives in the cache line that is used exclusively by the updating CPU'. --0uNolHhSuKIW4i3A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRRhjpAAoJEJDCuSvBvK1BRJ0P/3MKmIrnc+gwLQsT/lpj/tHN E1ttPCtDwiZUGpYi5ma32Mxw/06RKBOLB0cKWtqVoszZGbN0SbWrnJNMzMIdih5R yQh7TQiehFjCBSiGeFJwmreAqMNBj5N16AAvJIif2cPAU3qW7uRdNxkYztsmB3ds LAzxu4ce0M21bAOvMPLqlHrEi58SblC+nkGuZEghEIZzxmvyrK6ZZ4K4GpQ/h3cT r0zgJUEZJ7Id1p9yUrdistUkgBa/6ljYOdJZZLi3jm8I5hTq+YYdzoeNbIZKKB69 tyI3uzvCpMT9bTOrlFYyZ6ReyGy3dy3JubA1ZZA5lxla+eTTxqMADzKzBncVpp8/ hMhaP5Q98haI9PHWz9Z0Z+KU8ok8G8PD0gVnM/RbwLggInbTRUFcLdA8ESEJNfMY 9ZQofLyx8YsFbZ4rshuUecbSBFu42YXQvMBB2qoPi0kz7xWMYvMAMfBjjWJAuMRA DIvSwpPwewwA0Lr1cB5yBPglxhWqmZ7gEMUkh6hfUmUBVWslU9LD7iOSxgVXt/ab YVzHT2dHUuHhdyLFMGn1Ty5SbtJA+JwyQsOTUGVJSE588ffArspo6Sk5oAdRjVd+ OtCx4Y2+POyIrXARE+CYAnFNk+F+cCW6qTS1mvIg+vrFiiwvcyzKHMIAag4x3qWD XaVsgNalNA+l4h3WCBLj =eUSw -----END PGP SIGNATURE----- --0uNolHhSuKIW4i3A--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130317192634.GW3794>