This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: RFC: major runtime map changes
- From: Martin Hunt <hunt at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: "systemtap at sources dot redhat dot com" <systemtap at sources dot redhat dot com>
- Date: Thu, 20 Oct 2005 10:10:25 -0700
- Subject: Re: RFC: major runtime map changes
- Organization: Red Hat Inc
- References: <1129761252.4284.30.camel@monkey> <y0m7jc82npw.fsf@toenail.toronto.redhat.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