On 1/23/15 10:06 AM, Pawel Moll wrote:
As far as I understand (John?) POSIX timers can be used on any clockid?
So it would be possible to obtain a dynamic clock id, for example for my
exotic trace hardware (by any means necessary, like opening a char
device) and create a timer firing every 1 ms
On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
> Also, one would expect something like:
>
> default: {
> struct k_clock *kc = clockid_to_kclock(event->attr.clock);
> struct timespec ts;
> if (kc) {
>
On 1/23/15 10:06 AM, Pawel Moll wrote:
As far as I understand (John?) POSIX timers can be used on any clockid?
So it would be possible to obtain a dynamic clock id, for example for my
exotic trace hardware (by any means necessary, like opening a char
device) and create a timer firing every 1 ms
On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
Also, one would expect something like:
default: {
struct k_clock *kc = clockid_to_kclock(event-attr.clock);
struct timespec ts;
if (kc) {
On Wed, Jan 21, 2015 at 9:54 AM, Pawel Moll wrote:
> On Wed, 2015-01-21 at 17:44 +, John Stultz wrote:
>> That said, there is the dynamic posix clockids. I'm not sure if it
>> would make sense, but even if we don't bump MAX_CLOCKS, might there
>> be some case where someone wants to use a
On Wed, 2015-01-21 at 17:44 +, John Stultz wrote:
> That said, there is the dynamic posix clockids. I'm not sure if it
> would make sense, but even if we don't bump MAX_CLOCKS, might there
> be some case where someone wants to use a dynamic posix clock for the
> perf reference?
If I remember
On Wed, Jan 21, 2015 at 9:12 AM, Pawel Moll wrote:
> On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
>> On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
>> > Currently three clocks are implemented: CLOCK_REALITME = 0,
>> > CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The
On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
> On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
> > Currently three clocks are implemented: CLOCK_REALITME = 0,
> > CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
> > 5 bits wide to allow for future
On Wed, 2015-01-21 at 17:44 +, John Stultz wrote:
That said, there is the dynamic posix clockids. I'm not sure if it
would make sense, but even if we don't bump MAX_CLOCKS, might there
be some case where someone wants to use a dynamic posix clock for the
perf reference?
If I remember
On Wed, Jan 21, 2015 at 9:54 AM, Pawel Moll pawel.m...@arm.com wrote:
On Wed, 2015-01-21 at 17:44 +, John Stultz wrote:
That said, there is the dynamic posix clockids. I'm not sure if it
would make sense, but even if we don't bump MAX_CLOCKS, might there
be some case where someone wants to
On Wed, Jan 21, 2015 at 9:12 AM, Pawel Moll pawel.m...@arm.com wrote:
On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
Currently three clocks are implemented: CLOCK_REALITME = 0,
CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW =
On Mon, 2015-01-05 at 13:45 +, Peter Zijlstra wrote:
On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
Currently three clocks are implemented: CLOCK_REALITME = 0,
CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
5 bits wide to allow for future extension to
On Mon, Jan 5, 2015 at 5:45 AM, Peter Zijlstra wrote:
> On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
>> Currently three clocks are implemented: CLOCK_REALITME = 0,
>> CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
>> 5 bits wide to allow for future extension to
On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
> Currently three clocks are implemented: CLOCK_REALITME = 0,
> CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
> 5 bits wide to allow for future extension to custom, non-POSIX clock
> sources(MAX_CLOCK for those is
On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
Currently three clocks are implemented: CLOCK_REALITME = 0,
CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
5 bits wide to allow for future extension to custom, non-POSIX clock
sources(MAX_CLOCK for those is 16,
On Mon, Jan 5, 2015 at 5:45 AM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Nov 06, 2014 at 04:51:58PM +, Pawel Moll wrote:
Currently three clocks are implemented: CLOCK_REALITME = 0,
CLOCK_MONOTONIC = 1 and CLOCK_MONOTONIC_RAW = 2. The clock field is
5 bits wide to allow for future
This patch adds an option to sample value of an additional clock with
any perf event, with the the aim of allowing time correlation between
data coming from perf and other sources like hardware trace which is
timestamped with an external clock.
The idea is to generate periodic perf record
This patch adds an option to sample value of an additional clock with
any perf event, with the the aim of allowing time correlation between
data coming from perf and other sources like hardware trace which is
timestamped with an external clock.
The idea is to generate periodic perf record
18 matches
Mail list logo