Messages in this thread |  | | Subject | Re: [PATCH v7 06/10] trace: Add lock-free tracing_map | From | Tom Zanussi <> | Date | Mon, 29 Jun 2015 15:19:52 -0500 |
| |
On Fri, 2015-06-12 at 14:17 -0400, Steven Rostedt wrote: > On Mon, 8 Jun 2015 16:32:05 -0500 > Tom Zanussi <tom.zanussi@linux.intel.com> 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 <tom.zanussi@linux.intel.com> > > > > +/** > > + * 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); > > +} > > + >
|  |