linux-kernel - Re: [RFC][PATCH] tracing: Add __cpumask() macro to trace events to record cpumasks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 May 2014 15:30:41 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Javi Merino <javi.merino@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>
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@...icios.com> wrote:

> ----- Original Message -----
> > From: "Steven Rostedt" <rostedt@...dmis.org>
> > To: "LKML" <linux-kernel@...r.kernel.org>
> > Cc: "Javi Merino" <javi.merino@....com>, "Andrew Morton" <akpm@...ux-foundation.org>, "Mathieu Desnoyers"
> > <mathieu.desnoyers@...icios.com>, "Ingo Molnar" <mingo@...nel.org>, "Namhyung Kim" <namhyung@...nel.org>, "Jiri
> > Olsa" <jolsa@...hat.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


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