RFC: major runtime map changes

[Martin Hunt <hunt at redhat dot com>]

I am rewriting parts of the maps (associative arrays).

The big change is support for per-cpu or aggregated maps (pmaps).  pmaps
are really independent maps, one for each cpu. They are ideal for
storing statistics. They can be written quickly because only the map for
the current cpu is updated. But reading requires locking and reading
each per-cpu map and adding the result together.

Typically, reading statistics would be done only at probe end time, or
at periodic intervals, as in "top".

There are two possible ways to implement the locking. The obvious method
would be to have writers get a spinlock on their cpu-local map.  Then
readers get spinlocks on each cpu-local maps. Because spinlocks are
fast, this should have minimal overhead.

A second option would be to have no locks for reading or writing.
Instead we require all reads and writes to be done by the current cpu
only to its cpu-local map. This would require a read of a pmap to have a
workqueue read the local copy of the map for each cpu and update the
global statistics. A further optimization might be to have this global
statistics value for the pmap be updated automatically (say every 200ms)
so that any reads would just grab the cached value.

I'm planning to implement the first option, then when I get time,
implement the second and do some scalability comparisons.

The second big change is that I am planning to deprecate the current
two-part api to read and write to maps. Currently you call a function to
set a key, then either read or write a value to/from that key. This
seemed like a good idea before I implemented the macros to dynamically
create needed map APIs and when we didn't know how many datatypes we
would support.

So instead of something like:
  _stp_map_key_int64_int64_str (map, 1,2,"Ohio");
  _stp_map_set_str (map, "Columbus" );
I am planning on implementing
  _stp_map_set_iiss (map, 1,2,"Ohio", "Columbus");

Reads prevent a slight complication for locking because for strings and
stats we need to either return a pointer to the data in the map, or copy
that data to a supplied buffer.  For the former, locks need to be held
until the data is no longer accessed.  What would the translator guys
like?

I am planning to make the pmap API identical, except "pmap" will be used
in place of "map".  So, _stp_pmap_new(), _stp_pmap_get(), etc.

comments?