Messages in this thread | | | Date | Tue, 6 May 2014 15:30:41 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC][PATCH] tracing: Add __cpumask() macro to trace events to record cpumasks |
| |
On Tue, 6 May 2014 19:16:34 +0000 (UTC) Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> ----- Original Message ----- > > From: "Steven Rostedt" <rostedt@goodmis.org> > > To: "LKML" <linux-kernel@vger.kernel.org> > > Cc: "Javi Merino" <javi.merino@arm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Mathieu Desnoyers" > > <mathieu.desnoyers@efficios.com>, "Ingo Molnar" <mingo@kernel.org>, "Namhyung Kim" <namhyung@kernel.org>, "Jiri > > Olsa" <jolsa@redhat.com> > > Sent: Tuesday, May 6, 2014 1:22:38 PM > > Subject: [RFC][PATCH] tracing: Add __cpumask() macro to trace events to record cpumasks > > > > > > Being able to show a cpumask of events can be useful as some events > > may affect only some CPUs. There is no standard way to record the > > cpumask and converting it to a string is rather expensive during > > the trace as traces happen in hotpaths. It would be better to record > > the raw event mask and be able to parse it at print time. > > Why name the type cpumask especially ? The type could be a "bitmask", > and the specific field semantic in this case (field name) could > be "cpus", thus implying that this is a cpu mask. This would allow > using bitmasks for other things than cpu masks.
Hmm, sure, perhaps it would be better to call it bitmask instead. It basically is already.
> > Moreover, I've been thinking about eventually adding a bitmask associated > with an enumeration, so each bit of the bitmask could be associated with > an entry from an enumeration (a string). So having a bitmask type would > be a good step in that direction. For instance, the block layer > instrumentation could use this for the rwbs field, instead of > printing characters with blk_fill_rwbs(). This would save space and > cpu time at trace collection.
Perhaps.
-- Steve
| |