This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: major runtime map changes


On Thu, 2005-10-20 at 13:55 -0400, Frank Ch. Eigler wrote:

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

That is much more complex than what I proposed and all it does is save
some storage space. Sorts become a huge mess; it is not as easy as you
make it sound. And we also lose the ability to just call a simple
aggregation function and then treat the output exactly as a normal map,
reusing all the current map functions.

While I'm thinking about it, do we want to preserve the per-cpu data?
Would it ever make sense to print the statistics not aggregated over all
cpus, but per-cpu?

Having a separate aggregation map allows us to do that. It also allows
us to switch to option 2 and cache that map so it doesn't have to be
recomputed all the time.

If we do not want per-cpu data kept, then we have an option of having
the local maps cleared after each aggregation operation, increasing
efficiency and allowing us to save space by having smaller local maps.

Martin



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]