Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1260418
| From | Namhyung Kim <namhyung@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map |
| Date | 2015-11-02 08:10 +0100 |
| Message-ID | <qqhpD-2lR-3@gated-at.bofh.it> (permalink) |
| References | <qmsD0-1Xu-7@gated-at.bofh.it> <qmsMG-299-3@gated-at.bofh.it> <qoQUy-6fX-15@gated-at.bofh.it> <qp0hb-3KA-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi Tom,
On Thu, Oct 29, 2015 at 01:35:43PM -0500, Tom Zanussi wrote:
> Hi Namhyung,
>
> On Thu, 2015-10-29 at 17:31 +0900, Namhyung Kim wrote:
> > Hi Tom,
> >
> > On Thu, Oct 22, 2015 at 01:14:12PM -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
> > > 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>
> > > Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> > > ---
> > > +/**
> > > + * tracing_map_insert - Insert key and/or retrieve val from a tracing_map
> > > + * @map: The tracing_map to insert into
> > > + * @key: The key to insert
> > > + *
> > > + * Inserts a key into a tracing_map and creates and returns a new
> > > + * tracing_map_elt for it, or if the key has already been inserted by
> > > + * a previous call, returns the tracing_map_elt already associated
> > > + * with it. When the map was created, the number of elements to be
> > > + * allocated for the map was specified (internally maintained as
> > > + * 'max_elts' in struct tracing_map), and that number of
> > > + * tracing_map_elts was created by tracing_map_init(). This is the
> > > + * pre-allocated pool of tracing_map_elts that tracing_map_insert()
> > > + * will allocate from when adding new keys. Once that pool is
> > > + * exhausted, tracing_map_insert() is useless and will return NULL to
> > > + * signal that state.
> > > + *
> > > + * This is a lock-free tracing map insertion function implementing a
> > > + * modified form of Cliff Click's basic insertion algorithm. It
> > > + * requires the table size be a power of two. To prevent any
> > > + * possibility of an infinite loop we always make the internal table
> > > + * size double the size of the requested table size (max_elts * 2).
> > > + * Likewise, we never reuse a slot or resize or delete elements - when
> > > + * we've reached max_elts entries, we simply return NULL once we've
> > > + * run out of entries. Readers can at any point in time traverse the
> > > + * tracing map and safely access the key/val pairs.
> > > + *
> > > + * Return: the tracing_map_elt pointer val associated with the key.
> > > + * If this was a newly inserted key, the val will be a newly allocated
> > > + * and associated tracing_map_elt pointer val. If the key wasn't
> > > + * found and the pool of tracing_map_elts has been exhausted, NULL is
> > > + * returned and no further insertions will succeed.
> > > + */
> > > +struct tracing_map_elt *tracing_map_insert(struct tracing_map *map, void *key)
> > > +{
> > > + u32 idx, key_hash, test_key;
> > > + struct tracing_map_entry *entry;
> > > +
> > > + key_hash = jhash(key, map->key_size, 0);
> > > + if (key_hash == 0)
> > > + key_hash = 1;
> > > + idx = key_hash >> (32 - (map->map_bits + 1));
> > > +
> > > + while (1) {
> > > + idx &= (map->map_size - 1);
> > > + entry = TRACING_MAP_ENTRY(map->map, idx);
> > > + test_key = entry->key;
> > > +
> > > + if (test_key && test_key == key_hash && entry->val &&
> > > + keys_match(key, entry->val->key, map->key_size))
> > > + return entry->val;
> > > +
> > > + if (!test_key && !cmpxchg(&entry->key, 0, key_hash)) {
> > > + struct tracing_map_elt *elt;
> > > +
> > > + elt = get_free_elt(map);
> > > + if (!elt)
> > > + break;
> > > + memcpy(elt->key, key, map->key_size);
> > > + entry->val = elt;
> > > +
> > > + return entry->val;
> > > + }
> > > + idx++;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> >
> > IIUC this always insert new entry if no matching key found. And if
> > the map is full, it only fails after walking through the entries to
> > find an empty one, mark the entry with the key and call to
> > get_free_elt() returns NULL. As more key added, it worsenes the
> > problem since more entries will be marked with no value IMHO.
> >
> > I can see you checked hist_data->drops in the next patch to work
> > around this problem. But IMHO it's suboptimal since it cannot update
> > the existing entries too. I think it'd be better having lookup-only
> > version of this function and use it after it sees drops. The lookup
> > function can bail out from the loop if the insert doesn't mark empty
> > entry anymore IMHO.
> >
> > Thoughts?
> >
>
> The assumption has always been that once you have drops (i.e.
> tracing_map_insert() returns NULL), the data can't really be trusted any
> more and tracing should just stop (and presumably be restarted with a
> bigger table). It doesn't mean that the data is completely useless,
> just that it no longer can be assumed to have captured all the events
> over the tracing run. Having a lookup-only version for the purpose of
> updating only existing entries sort of illustrates the problem even
> better - in that case only the events that already have entries in the
> table will be included while the events that don't yet have entries will
> be ignored, skewing the value of the data.
I thought it'd be better if users can see which one is the real drop
or not. IOW if drop count is much smaller than the normal event
count, [s]he might want to ignore the occasional drops. Otherwise,
[s]he should restart with a bigger table. This requires accurate
counts of events and drops though.
>
> On the other hand, if users do end up calling this even after it's
> returned NULL, we should make sure it doesn't result in an infinite
> loop, and cap the number of iterations through the loop. tracing_map
> wasn't really meant to be generally reusable - it was separated out so
> it could be shared between two tracers - but it wouldn't hurt to add
> that check just in case...
Right.
Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 00/28] tracing: 'hist' triggers Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:20 +0200
[PATCH v11 16/28] tracing: Add hist trigger 'sym' and 'sym-offset' modifiers Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:20 +0200
[PATCH v11 12/28] tracing: Add hist trigger support for user-defined sorting ('sort=' param) Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:20 +0200
Re: [PATCH v11 12/28] tracing: Add hist trigger support for user-defined sorting ('sort=' param) Namhyung Kim <namhyung@kernel.org> - 2015-11-02 09:10 +0100
[PATCH v11 01/28] tracing: Update cond flag when enabling or disabling a trigger Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 27/28] kselftests/ftrace : Add event trigger testcases Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 10/28] tracing: Add hist trigger support for multiple values ('vals=' param) Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
Re: [PATCH v11 10/28] tracing: Add hist trigger support for multiple values ('vals=' param) Namhyung Kim <namhyung@kernel.org> - 2015-11-02 08:50 +0100
[PATCH v11 06/28] tracing: Add a per-event-trigger 'paused' field Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 25/28] tracing: Add support for named triggers Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 18/28] tracing: Add hist trigger 'syscall' modifier Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 03/28] tracing: Make event trigger functions available Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
[PATCH v11 04/28] tracing: Add event record param to trigger_ops.func() Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
Re: [PATCH 00/28] tracing: 'hist' triggers Steven Rostedt <rostedt@goodmis.org> - 2015-10-22 20:30 +0200
Re: [PATCH 00/28] tracing: 'hist' triggers Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:40 +0200
[PATCH v11 05/28] tracing: Add get_syscall_name() Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-22 20:30 +0200
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Namhyung Kim <namhyung@kernel.org> - 2015-10-29 09:40 +0100
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-10-29 19:40 +0100
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Namhyung Kim <namhyung@kernel.org> - 2015-11-02 08:10 +0100
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-11-04 02:50 +0100
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Namhyung Kim <namhyung@kernel.org> - 2015-11-04 03:30 +0100
Re: [PATCH v11 08/28] tracing: Add lock-free tracing_map Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-11-04 04:00 +0100
Re: [PATCH 00/28] tracing: 'hist' triggers Namhyung Kim <namhyung@kernel.org> - 2015-11-05 15:50 +0100
RE: [PATCH 00/28] tracing: 'hist' triggers 平松雅巳 / HIRAMATU,MASAMI <masami.hiramatsu.pt@hitachi.com> - 2015-11-05 16:00 +0100
Re: [PATCH 00/28] tracing: 'hist' triggers Tom Zanussi <tom.zanussi@linux.intel.com> - 2015-11-05 23:20 +0100
Re: [PATCH 00/28] tracing: 'hist' triggers Namhyung Kim <namhyung@kernel.org> - 2015-11-06 00:20 +0100
csiph-web