From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28147 invoked by alias); 20 Oct 2005 15:49:10 -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 28130 invoked by uid 22791); 20 Oct 2005 15:49:07 -0000 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: Martin Hunt Cc: systemtap@sources.redhat.com Subject: Re: RFC: major runtime map changes References: <1129761252.4284.30.camel@monkey> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 20 Oct 2005 15:49:00 -0000 In-Reply-To: <1129761252.4284.30.camel@monkey> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-q4/txt/msg00066.txt.bz2 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? > 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? > 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? > 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. - FChE