RFC: major runtime map changes

[Frank Ch. Eigler]

hunt wrote:

> [...]  The big change is support for per-cpu or aggregated maps
> (pmaps).  pmaps are really independent maps, one for each cpu. [...]

How would iteration/sorting work on these pmaps, considering that
different per-cpu maps will in general have different set of index
tuples?

> 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.  [...]

Yes, and if the theory that reading (printing/querying) statistics
objects is rare, then these locks will suffer no contention.  Is it
necessary for the runtime to implement any of this locking, or can it
continue to leave that entire chore to the translator?

> A second option would be to have no locks for reading or writing.
> [...] 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. [...]

I suggest not even prototyping this until someone can produce evidence
that the first style imposes unacceptable performance constraints.

> The second big change is that I am planning to deprecate the current
> two-part api to read and write to maps. [...]

Hurrah.  Will this accomplish the needs of bug #1275, so that we can
read-lock foreach again?

> 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.  [...]

Copying to a translator-supplied buffer would be fine.  But again,
since the translator is happy to hold read/write locks as needed
around runtime calls, the runtime can also just return pointers and
let the generated code do the copy.


- FChE