[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4E57F164.6020406@gmail.com>
Date: Fri, 26 Aug 2011 13:17:56 -0600
From: David Ahern <dsahern@...il.com>
To: Stephane Eranian <eranian@...gle.com>
CC: linux-kernel@...r.kernel.org, peterz@...radead.org, mingo@...e.hu,
acme@...hat.com, ming.m.lin@...el.com
Subject: Re: [PATCH] perf: collect multiplexing timing information in perf
record
On 08/26/2011 12:02 PM, Stephane Eranian wrote:
>>> +static int
>>> +sample_read2u64(const u64 *array, u64 fmt)
>>> +{
>>> + u64 nr = 1;
>>> + int ret = 1; /* nr or value */
>>> +
>>> + if (fmt & PERF_FORMAT_TOTAL_TIME_ENABLED)
>>> + ret++;
>>> +
>>> + if (fmt & PERF_FORMAT_TOTAL_TIME_RUNNING)
>>> + ret++;
>>> +
>>> + if (fmt & PERF_FORMAT_GROUP) {
>>> + nr = *(u64 *)array;
>>> + ret += nr;
>>> + }
>>> +
>>> + if (fmt & PERF_FORMAT_ID)
>>> + ret += nr;
>>
>> Why not add
>> struct read_format {
>> u64 value;
>> u64 time_enabled;
>> u64 time_running;
>> u64 id;
>> };
>>
>> to perf_sample and save the data there?
>>
> I am not following you here.
> Are you talking about the kernel API or perf tool internals?
>
> The only way to have timing saved in each sample is via
> PERF_SAMPLE_READ and a read_format which includes
> time_enabled + time_running.
I meant in that function you added above -- sample_read2u64. You are
moving the array pointer forward and essentially throwing away data that
was pushed to userspace. Why not add a struct and save that data for use
elsewhere in the builtin code? And the order of the data is a function
of whether PERF_FORMAT_GROUP is set (see perf_event.h file).
David
--
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/
Powered by blists - more mailing lists