Re: [RFC][PATCH v2] tracing: Add __bitmask() macro to trace events to cpumasks and other bitmasks

[Steven Rostedt]

On Wed, 7 May 2014 11:40:21 +0000 (UTC)
Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote:

> ----- Original Message -----
> > From: "Steven Rostedt" <rostedt@xxxxxxxxxxx>
> > To: "LKML" <linux-kernel@xxxxxxxxxxxxxxx>
> > Cc: "Mathieu Desnoyers" <mathieu.desnoyers@xxxxxxxxxxxx>, "Javi Merino" <javi.merino@xxxxxxx>, "Andrew Morton"
> > <akpm@xxxxxxxxxxxxxxxxxxxx>, "Ingo Molnar" <mingo@xxxxxxxxxx>, "Namhyung Kim" <namhyung@xxxxxxxxxx>, "Jiri Olsa"
> > <jolsa@xxxxxxxxxx>
> > Sent: Tuesday, May 6, 2014 11:12:38 PM
> > Subject: [RFC][PATCH v2] tracing: Add __bitmask() macro to trace events to cpumasks and other bitmasks
> > 
> > 
> > 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.
> 
> Hi Steven,
> 
> OK. Changing cpumask into bitmask helps making this more generic. Now
> I'm concerned about another topic: the type backing the bitmask, as well
> as its endianness, have an important impact when storing and reading
> the trace on different machines. This is not a problem cpumask typically
> has, because the test_bit() and set bit APIs are always used from within
> the kernel.
> 
> Looking at:
> 
> /**
>  * test_bit - Determine whether a bit is set
>  * @nr: bit number to test
>  * @addr: Address to start counting from
>  */
> static inline int test_bit(int nr, const volatile unsigned long *addr)
> {
>         return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG-1)));
> }
> 
> We notice that the kernel's bit operations use an unsigned long
> as "backing type" for the bitfield, with a native kernel endianness.
> 
> Therefore, the trace reader needs to take into account those two
> informations (backing type size, and endianness) in order to get the
> bit order right.
> 
> I remember that you made sure Ftrace's event description files expose
> the endianness of the kernel, which partially takes care of this
> concern, but how do you plan exposing the bitmask backing type size ?
> (unsigned long maps to 32-bit or 64-bit depending on the architecture).

Well, actually, the files don't expose endianess, but that is done by
the userspace tracer running on the machine. I'm not sure of any
machine that would have userspace and kernel space endianess different.

But the 32-bit vs 64-bit is exposed. Not really directly, but the way
traceevent finds this out is with pevent->header_page_size_size. That
is, in /debug/tracing/events/header_page the field "commit" is of size
long in the kernel. It's 8 for 64bit and 4 for 32bit.

This works even if userspace is 32 and kernel is 64.

With both endian and long size, it should be trivial for the reader to
be able to parse the cpumask on any machine.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/