[CFR][CFT] counter(9): new API for faster and raceless counters

[Gleb Smirnoff]

  Pawel,

On Wed, Apr 03, 2013 at 01:26:07AM +0200, Pawel Jakub Dawidek wrote:
P> >   Together with Konstantin Belousov (kib@) we developed a new API that is
P> > initially purposed for (but not limited to) collecting statistical
P> > data in kernel.
P> 
P> Is there any plan to implement universal way of exporting those
P> statistics out of the kernel?
P> 
P> Solaris has a framework for in-kernel statistics, which are exported via
P> kstat tool. For ZFS I export them via sysctl. If you have ZFS loaded you
P> can try 'sysctl kstat'.

There are already primitives for sysctl in the branch:

     #include <sys/sysctl.h>

     SYSCTL_COUNTER_U64(parent, nbr, name, access, ptr, val, descr);

     SYSCTL_ADD_COUNTER_U64(ctx, parent, nbr, name, access, ptr, descr);

I do not think that every counter(9) in system should create an oid
automatically. We are going to have counters per ipfw and per pf rule.

P> It would be nice for counter_u64_alloc() to take additional argument
P> 'name' and to create sysctl for the counter automatically. We could then
P> slowly start migrating userland tools to use sysctls (or some wrapper
P> userland API), but we immediately make those statistics available for
P> use in scripts.

Oh, in this bikeshed I am somewhere between your plan and the XML junta :)
I'd better stay away from this discussion :) Let's keep topic on the new
primitive.

Just keep in mind that having a name would require another memory
allocation, from normal not per-cpu malloc(9).

P> > o Tiny API for counter(9):
P> > 
P> >      counter_u64_t
P> >      counter_u64_alloc(int wait);
P> > 
P> >      void
P> >      counter_u64_free(counter_u64_t cnt);
P> > 
P> >      void
P> >      counter_u64_add(counter_u64_t cnt, uint64_t inc);
P> > 
P> >      uint64_t
P> >      counter_u64_fetch(counter_u64_t cnt);
P> 
P> Do you really expect other types in the future? If so, could we at least
P> create generic counter_t that internally keeps the type?

We will probably have signed 64-bit, actually allocated from the same
zone.

A type keeping type would require either additional allocation from malloc(9)
or UMA directly, that would store the type, or we will store type in every
per-cpu copy, wasting memory.

-- 
Totus tuus, Glebius.