From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15348 invoked by alias); 20 Oct 2005 17:15:16 -0000 Mailing-List: contact systemtap-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sources.redhat.com Received: (qmail 15324 invoked by uid 22791); 20 Oct 2005 17:15:13 -0000 Subject: Re: RFC: major runtime map changes From: Martin Hunt To: "Frank Ch. Eigler" Cc: "systemtap@sources.redhat.com" In-Reply-To: References: <1129761252.4284.30.camel@monkey> Content-Type: text/plain Organization: Red Hat Inc Date: Thu, 20 Oct 2005 17:15:00 -0000 Message-Id: <1129828225.4047.18.camel@monkey> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-SW-Source: 2005-q4/txt/msg00067.txt.bz2 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