RFC: major runtime map changes

[Frank Ch. Eigler]

Hi -

hunt wrote:

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

OK.  Maybe it will be useful to avoid such copying, and do it
virtually, something like this:

- for pmap->lookup(key) iterate over map[cpu]->lookup(key) and aggregate
  on the fly

- for iteration, iterate over map[0], aggregating same keys over
  map[1..N], then follow that with an iteration over map[1] that skips
  those key tuples already handled for map[0], and so on.  The
  complexity of this may not be smaller than plain merge-then-iterate,
  but would eliminate data copying.

- for sorted iteration, sort each map[cpu], then do per-step
  "external merge"


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20051020/9fb554ff/attachment.sig>