Re: RFC: major runtime map changes

[Martin Hunt <hunt at redhat dot com>]

On Thu, 2005-10-20 at 11:48 -0400, Frank Ch. Eigler wrote:
> 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?

The per-cpu maps are first aggregated into one map. 

Creating a pmap will actually create N+1 maps where N = number of cpus.
The extra map will be the aggregation map.  When _stp_pmap_start(),
stp_pmap_print(), or _stp_pmap_sort() are called, the per-cpu maps are
summed into the aggregation map.

> > 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?

I'll probably leave it 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?

Yes.

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

Sounds good.

Martin