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..
You must not expect lock-step updates for this to work.
Not required unless the tool is expected to process the new namespace data..
Thanks
Hari
