[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2af6cd8b-46f3-b60d-581f-30269ea65d53@linux.vnet.ibm.com>
Date: Wed, 21 Dec 2016 21:26:12 +0530
From: Hari Bathini <hbathini@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: ast@...com, lkml <linux-kernel@...r.kernel.org>, acme@...nel.org,
alexander.shishkin@...ux.intel.com, mingo@...hat.com,
daniel@...earbox.net, rostedt@...dmis.org,
Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
ebiederm@...ssion.com, sargun@...gun.me,
Aravinda Prasad <aravinda@...ux.vnet.ibm.com>,
brendan.d.gregg@...il.com
Subject: Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include
namespaces related info
On Wednesday 21 December 2016 06:54 PM, Peter Zijlstra wrote:
> On Wed, Dec 21, 2016 at 06:39:01PM +0530, Hari Bathini wrote:
>> Hi Peter,
>>> 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..?
> Yes, if you add a nr_namespaces field its always parsable. If an old
> tool finds more namespace than it has 'names' for it can always display
> the raw index number. If a new tool finds the array short, it will not
> display the missing ones.
>
Sure, Peter. Will post the next version as soon as
I am back from vacation..
Thanks
Hari
Powered by blists - more mailing lists