Hi Peter,
On Saturday 17 December 2016 01:35 AM, Peter Zijlstra wrote:
On Fri, Dec 16, 2016 at 11:51:20PM +0530, Hari Bathini wrote:
Hi Peter,
On Friday 16 December 2016 01:27 PM, Peter Zijlstra wrote:
On Fri, Dec 16, 2016 at 11:57:47AM +0530, Hari Bathini wrote:
On Friday 16 December 2016 12:16 AM, Peter Zijlstra wrote:
On Fri, Dec 16, 2016 at 12:07:06AM +0530, Hari Bathini wrote:
+struct perf_ns_link_info {
+ __u64 dev;
+ __u64 ino;
+};
+
+enum {
+ NET_NS_INDEX = 0,
+ UTS_NS_INDEX = 1,
+ IPC_NS_INDEX = 2,
+ PID_NS_INDEX = 3,
+ USER_NS_INDEX = 4,
+ MNT_NS_INDEX = 5,
+ CGROUP_NS_INDEX = 6,
+
+ NAMESPACES_MAX, /* maximum available namespaces */
+};
+
enum perf_event_type {
/*
@@ -862,6 +880,17 @@ enum perf_event_type {
*/
PERF_RECORD_SWITCH_CPU_WIDE = 15,
+ /*
+ * struct {
+ * struct perf_event_header header;
+ * u32 pid;
+ * u32 tid;
+ * struct namespace_link_info link_info[NAMESPACES_MAX];
+ * struct sample_id sample_id;
+ * };
+ */
+ PERF_RECORD_NAMESPACES = 16,
+
PERF_RECORD_MAX, /* non-ABI */
};
What happens if a future kernel adds another namespace?
No impact unless NAMESPACES_MAX in include/uapi/linux/perf_event.h is
updated to accommodate that..
And if it is updated, the corresponding change is expected in perf-tool as
well..
And what happens if you try and process old data files with the new
tools or the other way around?
It works fine either way. I tested that..
I don't see how the tool can parse old records (with NAMESPACES_MAX ==
7) if you set its NAMESPACES_MAX to say 10.
Then it will expect the link_info array to be 10 entries and either read
past the end of the record (if !sample_all) or try and interpret
sample_id as link_info records.
Right. There will be inconsistency with data the perf tool tries to read
beyond
what the kernel supports. IIUC, you mean, include nr_namespaces field in the
record and warn the user if it doesn't match with the one perf-tool supports
before proceeding..?
Thanks
Hari
PS: I am on vacation. Will post next version early January.
