svn commit: r248438 - projects/counters/share/man/man9
Konstantin Belousov
kostikbel at gmail.com
Sun Mar 17 19:26:43 UTC 2013
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
>
> 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'.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20130317/2b72732e/attachment.sig>
More information about the svn-src-projects
mailing list