[lkml]   [2015]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 06/10] trace: Add lock-free tracing_map
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

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.



> > 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:
> >
> >
> >
> >
> > 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);
> > +}
> > +

 \ /
  Last update: 2015-06-29 22:41    [W:0.070 / U:1.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site