From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753177AbbF2UVQ (ORCPT ); Mon, 29 Jun 2015 16:21:16 -0400 Received: from mga11.intel.com ([192.55.52.93]:9788 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752953AbbF2UVG (ORCPT ); Mon, 29 Jun 2015 16:21:06 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,372,1432623600"; d="scan'208";a="752747642" Message-ID: <1435609192.31724.136.camel@picadillo> Subject: Re: [PATCH v7 06/10] trace: Add lock-free tracing_map From: Tom Zanussi To: Steven Rostedt Cc: daniel.wagner@bmw-carit.de, masami.hiramatsu.pt@hitachi.com, namhyung@kernel.org, josh@joshtriplett.org, andi@firstfloor.org, linux-kernel@vger.kernel.org In-Reply-To: <20150612141731.01232907@gandalf.local.home> References: <20150612141731.01232907@gandalf.local.home> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Jun 2015 15:19:52 -0500 Mime-Version: 1.0 X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2015-06-12 at 14:17 -0400, Steven Rostedt wrote: > On Mon, 8 Jun 2015 16:32:05 -0500 > Tom Zanussi wrote: > > > Add tracing_map, a special-purpose lock-free map for tracing. > > > > tracing_map is designed to aggregate or 'sum' one or more values > > associated with a specific object of type tracing_map_elt, which > > What is "elt"? I don't see it explained anywhere. > It's short for 'element' but I guess that's not why you're asking about it. Sorry for the confusion - I've written up a description of the data structures and how they work, which is included in my next revision. Here's that section, from the new tracing_map.h: /* * This is an overview of the tracing_map data structures and how they * relate to the tracing_map API. The details of the algorithms * aren't discussed here - this is just a general overview of the data * structures and how they interact with the API. * * The central data structure of the tracing_map is an initially * zeroed array of struct tracing_map_entry (stored in the map field * of struct tracing_map). tracing_map_entry is a very simple data * structure containing only two fields: a 32-bit unsigned 'key' * variable and a pointer named 'val'. This array of struct * tracing_map_entry is essentially a hash table which will be * modified by a single function, tracing_map_insert(), but which can * be traversed and read by a user at any time (though the user does * this indirectly via an array of tracing_map_sort_entry - see the * explanation of that data structure in the discussion of the * sorting-related data structures below). * * The central function of the tracing_map API is * tracing_map_insert(). tracing_map_insert() hashes the * arbitrarily-sized key passed into it into a 32-bit unsigned key. * It then uses this key, truncated to the array size, as an index * into the array of tracing_map_entries. If the value of the 'key' * field of the tracing_map_entry found at that location is 0, then * that entry is considered to be free and can be claimed, by * replacing the 0 in the 'key' field of the tracing_map_entry with * the new 32-bit hashed key. Once claimed, that tracing_map_entry's * 'val' field is then used to store a unique element which will be * forever associated with that 32-bit hashed key in the * tracing_map_entry. * * That unique element now in the tracing_map_entry's 'val' field is * an instance of tracing_map_elt, where 'elt' in the latter part of * that variable name is short for 'element'. The purpose of a * tracing_map_elt is to hold values specific to the the particular * 32-bit hashed key it's assocated with. Things such as the unique * set of aggregated sums associated with the 32-bit hashed key, along * with a copy of the full key associated with the entry, and which * was used to produce the 32-bit hashed key. * * When tracing_map_create() is called to create the tracing map, the * user specifies (indirectly via the map_bits param, the details are * unimportant for this discussion) the maximum number of elements * that the map can hold (stored in the max_elts field of struct * tracing_map). This is the maximum possible number of * tracing_map_entries in the tracing_map_entry array which can be * 'claimed' as described in the above discussion, and therefore is * also the maximum number of tracing_map_elts that can be associated * with the tracing_map_entry array in the tracing_map. Because of * the way the insertion algorithm works, the size of the allocated * tracing_map_entry array is always twice the maximum number of * elements (2 * max_elts). This value is stored in the map_size * field of struct tracing_map. * * Because tracing_map_insert() needs to work from any context, * including from within the memory allocation functions themselves, * both the tracing_map_entry array and a pool of max_elts * tracing_map_elts are pre-allocated before any call is made to * tracing_map_insert(). * * The tracing_map_entry array is allocated as a single block by * tracing_map_create(). * * Because the tracing_map_elts are much larger objects and can't * generally be allocated together as a single large array without * failure, they're allocated individually, by tracing_map_init(). * * The pool of tracing_map_elts are allocated by tracing_map_init() * rather than by tracing_map_create() because at the time * tracing_map_create() is called, there isn't enough information to * create the tracing_map_elts. Specifically,the user first needs to * tell the tracing_map implementation how many fields the * tracing_map_elts contain, and which types of fields they are (key * or sum). The user does this via the tracing_map_add_sum_field() * and tracing_map_add_key_field() functions, following which the user * calls tracing_map_init() to finish up the tracing map setup. The * array holding the pointers which make up the pre-allocated pool of * tracing_map_elts is allocated as a single block and is stored in * the elts field of struct tracing_map. * * There is also a set of structures used for sorting that might * benefit from some minimal explanation. * * struct tracing_map_sort_key is used to drive the sort at any given * time. By 'any given time' we mean that a different * tracing_map_sort_key will be used at different times depending on * whether the sort currently being performed is a primary or a * secondary sort. * * The sort key is very simple, consisting of the field index of the * tracing_map_elt field to sort on (which the user saved when adding * the field), and whether the sort should be done in an ascending or * descending order. * * For the convenience of the sorting code, a tracing_map_sort_entry * is created for each tracing_map_elt, again individually allocated * to avoid failures that might be expected if allocated as a single * large array of struct tracing_map_sort_entry. * tracing_map_sort_entry instances are the objects expected by the * various internal sorting functions, and are also what the user * ultimately receives after calling tracing_map_sort_entries(). * Because it doesn't make sense for users to access an unordered and * sparsely populated tracing_map directly, the * tracing_map_sort_entries() function is provided so that users can * retrieve a sorted list of all existing elements. In addition to * the associated tracing_map_elt 'elt' field contained within the * tracing_map_sort_entry, which is the object of interest to the * user, tracing_map_sort_entry objects contain a number of additional * fields which are used for caching and internal purposes and can * safely be ignored. */ Thanks, Tom > > > is associated by the map to a given key. > > > > It provides various hooks allowing per-tracer customization and is > > separated out into a separate file in order to allow it to be shared > > between multiple tracers, but isn't meant to be generally used outside > > of that context. > > > > The tracing_map implementation was inspired by lock-free map > > algorithms originated by Dr. Cliff Click: > > > > http://www.azulsystems.com/blog/cliff/2007-03-26-non-blocking-hashtable > > http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf > > > > Signed-off-by: Tom Zanussi > > > > +/** > > + * tracing_map_update_sum - Add a value to a tracing_map_elt's sum > > + * @elt: The tracing_map_elt > > Not a very useful comment, as I have no idea what "elt" is. > > I'll continue to review this patch about the mysterious element "elt". > > -- Steve > > > + * @i: The index of the given sum associated with the tracing_map_elt > > + * @n: The value to add to the sum > > + * > > + * Add n to sum i associated with the specified tracing_map_elt > > + * instance. The index i is the index returned by the call to > > + * tracing_map_add_sum_field() when the tracing map was set up. > > + */ > > +void tracing_map_update_sum(struct tracing_map_elt *elt, unsigned int i, u64 n) > > +{ > > + atomic64_add(n, &elt->fields[i].sum); > > +} > > + >