* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
> Hi -
>
> On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
> > [...]
> > > All this complexity is to be justified by keeping the raw prev/next
> > > pointers from being sent to a naive tracer? It seems to me way out of
> > >
* Frank Ch. Eigler ([EMAIL PROTECTED]) wrote:
Hi -
On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
[...]
All this complexity is to be justified by keeping the raw prev/next
pointers from being sent to a naive tracer? It seems to me way out of
proportion.
Damn,
Hi -
On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
> [...]
> > All this complexity is to be justified by keeping the raw prev/next
> > pointers from being sent to a naive tracer? It seems to me way out of
> > proportion.
>
> Damn, and I just blew away all my marker code for
On Fri, 18 Jan 2008, Frank Ch. Eigler wrote:
>
> All this complexity is to be justified by keeping the raw prev/next
> pointers from being sent to a naive tracer? It seems to me way out of
> proportion.
Damn, and I just blew away all my marker code for something like this ;-)
Actually, you
Hi -
On Fri, Jan 18, 2008 at 06:19:29PM -0500, Mathieu Desnoyers wrote:
> [...]
> Almost.. I would add :
>
> static int trace_switch_to_enabled;
>
> > static inline trace_switch_to(struct task_struct *prev,
> > struct task_struct *next)
> > {
> if
Hi -
On Fri, Jan 18, 2008 at 05:49:19PM -0500, Steven Rostedt wrote:
> [...]
> > But I have not seen a lot of situations where that kind of glue-code was
> > needed, so I think it makes sense to keep markers simple to use and
> > efficient for the common case.
> >
> > Then, in this glue-code, we
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> On Fri, 18 Jan 2008, Mathieu Desnoyers wrote:
> >
> > But I have not seen a lot of situations where that kind of glue-code was
> > needed, so I think it makes sense to keep markers simple to use and
> > efficient for the common case.
> >
> > Then, in
On Fri, 18 Jan 2008, Mathieu Desnoyers wrote:
>
> But I have not seen a lot of situations where that kind of glue-code was
> needed, so I think it makes sense to keep markers simple to use and
> efficient for the common case.
>
> Then, in this glue-code, we can put trace_mark() and calls to
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Thu, 17 Jan 2008, Frank Ch. Eigler wrote:
>
> > Hi -
> >
> > On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> > > [...]
> > > + trace_mark(kernel_sched_schedule,
> > > + "prev_pid %d next_pid %d prev_state
On Fri, 18 Jan 2008, Mathieu Desnoyers wrote:
But I have not seen a lot of situations where that kind of glue-code was
needed, so I think it makes sense to keep markers simple to use and
efficient for the common case.
Then, in this glue-code, we can put trace_mark() and calls to in-kernel
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Fri, 18 Jan 2008, Mathieu Desnoyers wrote:
But I have not seen a lot of situations where that kind of glue-code was
needed, so I think it makes sense to keep markers simple to use and
efficient for the common case.
Then, in this
On Fri, 18 Jan 2008, Frank Ch. Eigler wrote:
All this complexity is to be justified by keeping the raw prev/next
pointers from being sent to a naive tracer? It seems to me way out of
proportion.
Damn, and I just blew away all my marker code for something like this ;-)
Actually, you just
Hi -
On Fri, Jan 18, 2008 at 06:19:29PM -0500, Mathieu Desnoyers wrote:
[...]
Almost.. I would add :
static int trace_switch_to_enabled;
static inline trace_switch_to(struct task_struct *prev,
struct task_struct *next)
{
if (likely(!trace_switch_to_enabled))
Hi -
On Fri, Jan 18, 2008 at 05:49:19PM -0500, Steven Rostedt wrote:
[...]
But I have not seen a lot of situations where that kind of glue-code was
needed, so I think it makes sense to keep markers simple to use and
efficient for the common case.
Then, in this glue-code, we can put
On Thu, 17 Jan 2008, Frank Ch. Eigler wrote:
> Hi -
>
> On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> > [...]
> > + trace_mark(kernel_sched_schedule,
> > + "prev_pid %d next_pid %d prev_state %ld",
> > + prev->pid, next->pid, prev->state);
>
Hi -
On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> [...]
> + trace_mark(kernel_sched_schedule,
> + "prev_pid %d next_pid %d prev_state %ld",
> + prev->pid, next->pid, prev->state);
> [...]
> But...
>
> Tracers that want to do a bit more work,
> > > >
> > > > One thing I want to clear up. The major difference between this
> > > > latency_tracer and LTTng is what we consider fast paths. The latency
> > > > tracer is recording things like enabling and disabling interrupts,
> > > > preempt
> > > > count changes, or simply profiling all
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
>
> Or could we map a per-thread page that would contradict this
> "definition" ?
Over my dead body.
It's been done before. Many times. It's horrible, and means that you need
to flush the TLB on context switches between threads and cannot share
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Thu, 17 Jan 2008, Paul Mackerras wrote:
> >
> > It's very hard to do a per-thread counter in the VDSO, since threads
> > in the same process see the same memory, by definition. You'd have to
> > have an array of counters and have some way for
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Thu, 17 Jan 2008, Paul Mackerras wrote:
> >
> > It's very hard to do a per-thread counter in the VDSO, since threads
> > in the same process see the same memory, by definition. You'd have to
> > have an array of counters and have some way for
>
> Crazy ideas :
>
> Could we do something along the lines of the thread local storage ?
>
> Or could we map a per-thread page that would contradict this
> "definition" ?
When working on lguest64, I implemented a "per CPU" shadow page. That the
process of a guest running on one real CPU, could
Crazy ideas :
Could we do something along the lines of the thread local storage ?
Or could we map a per-thread page that would contradict this
definition ?
When working on lguest64, I implemented a per CPU shadow page. That the
process of a guest running on one real CPU, could never see
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Thu, 17 Jan 2008, Paul Mackerras wrote:
It's very hard to do a per-thread counter in the VDSO, since threads
in the same process see the same memory, by definition. You'd have to
have an array of counters and have some way for each thread
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
Or could we map a per-thread page that would contradict this
definition ?
Over my dead body.
It's been done before. Many times. It's horrible, and means that you need
to flush the TLB on context switches between threads and cannot share the
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Thu, 17 Jan 2008, Paul Mackerras wrote:
It's very hard to do a per-thread counter in the VDSO, since threads
in the same process see the same memory, by definition. You'd have to
have an array of counters and have some way for each thread
One thing I want to clear up. The major difference between this
latency_tracer and LTTng is what we consider fast paths. The latency
tracer is recording things like enabling and disabling interrupts,
preempt
count changes, or simply profiling all function calls. Those
On Thu, 17 Jan 2008, Frank Ch. Eigler wrote:
Hi -
On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
[...]
+ trace_mark(kernel_sched_schedule,
+ prev_pid %d next_pid %d prev_state %ld,
+ prev-pid, next-pid, prev-state);
[...]
But...
Hi -
On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
[...]
+ trace_mark(kernel_sched_schedule,
+ prev_pid %d next_pid %d prev_state %ld,
+ prev-pid, next-pid, prev-state);
[...]
But...
Tracers that want to do a bit more work, like
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
> Mathieu Desnoyers writes:
>
> > Sorry for self-reply, but I thought, in the past, of a way to make this
> > possible.
> >
> > It would imply the creation of a new vsyscall : vgetschedperiod
> >
> > It would read a counter that would increment each
On Thu, 17 Jan 2008, Paul Mackerras wrote:
>
> It's very hard to do a per-thread counter in the VDSO, since threads
> in the same process see the same memory, by definition. You'd have to
> have an array of counters and have some way for each thread to know
> which entry to read. Also you'd
Mathieu Desnoyers writes:
> Sorry for self-reply, but I thought, in the past, of a way to make this
> possible.
>
> It would imply the creation of a new vsyscall : vgetschedperiod
>
> It would read a counter that would increment each time the thread is
> scheduled out (or in). It would be a per
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> It would imply the creation of a new vsyscall : vgetschedperiod
>
> It would read a counter that would increment each time the thread is
> scheduled out (or in). It would be a per thread counter (not a per cpu
> counter) so we can deal
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * john stultz ([EMAIL PROTECTED]) wrote:
> >
> > On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> > > Thanks John for doing this!
> > >
> > > (comments imbedded)
> > >
> > > On Wed, 16 Jan 2008, john stultz wrote:
> > > > + int
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > Yep. clocksource_get_cycles() ended up not being as useful as an helper
> > function (I was hoping the arch vsyscall implementations could use it,
> > but they've done too much optimization - although that may reflect a
> > need up the chain
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> > Thanks John for doing this!
> >
> > (comments imbedded)
> >
> > On Wed, 16 Jan 2008, john stultz wrote:
> > > + int num = !cs->base_num;
> > > + cycle_t offset = (now -
* john stultz ([EMAIL PROTECTED]) wrote:
> On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> > I would disable preemption in clocksource_get_basecycles. We would not
> > want to be scheduled out while we hold a pointer to the old array
> > element.
> >
> > > + int num = cs->base_num;
On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
> Thanks John for doing this!
>
> (comments imbedded)
>
> On Wed, 16 Jan 2008, john stultz wrote:
> > + int num = !cs->base_num;
> > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
> > + offset &= cs->mask;
> > +
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> > * john stultz ([EMAIL PROTECTED]) wrote:
> > >
> > > On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
> > > > On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
>
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> I would disable preemption in clocksource_get_basecycles. We would not
> want to be scheduled out while we hold a pointer to the old array
> element.
>
> > + int num = cs->base_num;
>
> Since you deal with base_num in a shared
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
>
>
> On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > > + int num = !cs->base_num;
> > > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
> >
> > !0 is not necessarily 1.
>
> Incorrect.
>
Hrm, *digging in my mailbox*, ah, here it is
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
>
> > + int num = !cs->base_num;
> > + cycle_t offset = (now - cs->base[!num].cycle_base_last);
>
> !0 is not necessarily 1.
Incorrect.
!0 _is_ necessarily 1. It's how all C logical operators work. If you find
a compiler that turns !x into
On Wed, 16 Jan 2008, Steven Rostedt wrote:
> On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > !0 is not necessarily 1. This is why I use cpu_synth->index ? 0 : 1 in
>
> How about simply "cpu_synth->index ^ 1"? Seems the best choice if you ask
> me, if all you are doing is changing it from 1
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
> * john stultz ([EMAIL PROTECTED]) wrote:
> >
> > On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
> > > On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > > > If you really want an seqlock free algorithm (I
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
>
> > - cycle_t offset = (now - cs->cycle_last) & cs->mask;
> > + /* First update the monotonic base portion.
> > +* The dual array update method allows for lock-free reading.
> > +*/
> > + int num = !cs->base_num;
> > + cycle_t offset
* john stultz ([EMAIL PROTECTED]) wrote:
>
> On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
> > On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > > If you really want an seqlock free algorithm (I _do_ want this for
> > > tracing!) :) maybe going in the RCU direction
Thanks John for doing this!
(comments imbedded)
On Wed, 16 Jan 2008, john stultz wrote:
>
> On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
>
> Completely un-tested, but it builds, so I figured I'd send it out for
> review.
heh, ok, I'll take it and run it.
>
> I'm not super sure the
On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
> On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > If you really want an seqlock free algorithm (I _do_ want this for
> > tracing!) :) maybe going in the RCU direction could help (I refer to my
> > RCU-based 32-to-64
On Jan 16, 2008 6:56 AM, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> If you really want an seqlock free algorithm (I _do_ want this for
> tracing!) :) maybe going in the RCU direction could help (I refer to my
> RCU-based 32-to-64 bits lockless timestamp counter extension, which
> could be
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> >
> > In-other-words, latency_tracer is LTTng-lite ;-)
> >
>
> If LTTng is already ported to your specific kernel, the learning-curve
> is not big at all. Here is what the latency_tracer over LTTng guide
> could look like :
>
> Well, once you have
Mathieu Desnoyers wrote:
> If LTTng is already ported to your specific kernel, the learning-curve
> is not big at all. Here is what the latency_tracer over LTTng guide
> could look like :
>
> Well, once you have LTTng in your kernel and have compiled and installed
> the ltt-control and lttv
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
...
> >
> > > >
> > > > - Disable preemption at the read-side :
> > > > it makes sure the pointer I get will point to a data structure that
> > > > will never change while I am in the preempt disabled code. (see *)
> > > > - I use per-cpu data to
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> * Steven Rostedt ([EMAIL PROTECTED]) wrote:
> >
> > Yeah, but if we replace the loop with a seq lock, then it would work.
> > albeit, more cacheline bouncing (caused by writes). (maybe not, see below)
> >
>
> Yes, but then you would trigger a
Steven Rostedt wrote:
> grmble. Then how do you trace preempt_disable? As my tracer does that
> (see the last patch in the series).
One way is to make a tracer_preempt_disable() and tracer_preempt_enable(),
both of which would be 'notrace'. You could probably optimize them
as well. The standard
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> * Steven Rostedt ([EMAIL PROTECTED]) wrote:
> >
> >
>
> > One thing I want to clear up. The major difference between this
> > latency_tracer and LTTng is what we consider fast paths. The latency
> > tracer is recording things like enabling
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
>
> On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> > > No, there's probably issues there too, but no need to worry about it,
> > > since I already showed that allowing for clocksource_accumulate to happen
> > > inside the get_monotonic_cycles loop
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> > No, there's probably issues there too, but no need to worry about it,
> > since I already showed that allowing for clocksource_accumulate to happen
> > inside the get_monotonic_cycles loop is already flawed.
> >
>
> Yep, I just re-read through
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> > Hrm, I will reply to the rest of this email in a separate mail, but
> > there is another concern, simpler than memory ordering, that just hit
> > me :
> >
> > If we have CPU A calling
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
> Hrm, I will reply to the rest of this email in a separate mail, but
> there is another concern, simpler than memory ordering, that just hit
> me :
>
> If we have CPU A calling clocksource_accumulate while CPU B is calling
> get_monotonic_cycles, but
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> [ CC'd Daniel Walker, since he had problems with this code ]
>
> On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
> >
> > I agree with you that I don't see how the compiler could reorder this.
> > So we forget about compiler barriers. Also, the clock
[ CC'd Daniel Walker, since he had problems with this code ]
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
>
> I agree with you that I don't see how the compiler could reorder this.
> So we forget about compiler barriers. Also, the clock source used is a
> synchronized clock source
[ CC'd Daniel Walker, since he had problems with this code ]
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
I agree with you that I don't see how the compiler could reorder this.
So we forget about compiler barriers. Also, the clock source used is a
synchronized clock source (get_cycles_sync
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
[ CC'd Daniel Walker, since he had problems with this code ]
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
I agree with you that I don't see how the compiler could reorder this.
So we forget about compiler barriers. Also, the clock source
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
Hrm, I will reply to the rest of this email in a separate mail, but
there is another concern, simpler than memory ordering, that just hit
me :
If we have CPU A calling clocksource_accumulate while CPU B is calling
get_monotonic_cycles, but
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
Hrm, I will reply to the rest of this email in a separate mail, but
there is another concern, simpler than memory ordering, that just hit
me :
If we have CPU A calling clocksource_accumulate
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
No, there's probably issues there too, but no need to worry about it,
since I already showed that allowing for clocksource_accumulate to happen
inside the get_monotonic_cycles loop is already flawed.
Yep, I just re-read through your
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
No, there's probably issues there too, but no need to worry about it,
since I already showed that allowing for clocksource_accumulate to happen
inside the get_monotonic_cycles loop is already
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
One thing I want to clear up. The major difference between this
latency_tracer and LTTng is what we consider fast paths. The latency
tracer is recording things like enabling and
Steven Rostedt wrote:
grmble. Then how do you trace preempt_disable? As my tracer does that
(see the last patch in the series).
One way is to make a tracer_preempt_disable() and tracer_preempt_enable(),
both of which would be 'notrace'. You could probably optimize them
as well. The standard
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
Yeah, but if we replace the loop with a seq lock, then it would work.
albeit, more cacheline bouncing (caused by writes). (maybe not, see below)
Yes, but then you would trigger a deadlock if you
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
...
- Disable preemption at the read-side :
it makes sure the pointer I get will point to a data structure that
will never change while I am in the preempt disabled code. (see *)
- I use per-cpu data to allow the read-side to
Mathieu Desnoyers wrote:
If LTTng is already ported to your specific kernel, the learning-curve
is not big at all. Here is what the latency_tracer over LTTng guide
could look like :
Well, once you have LTTng in your kernel and have compiled and installed
the ltt-control and lttv packages
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
In-other-words, latency_tracer is LTTng-lite ;-)
If LTTng is already ported to your specific kernel, the learning-curve
is not big at all. Here is what the latency_tracer over LTTng guide
could look like :
Well, once you have LTTng in your
On Jan 16, 2008 6:56 AM, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
If you really want an seqlock free algorithm (I _do_ want this for
tracing!) :) maybe going in the RCU direction could help (I refer to my
RCU-based 32-to-64 bits lockless timestamp counter extension, which
could be turned
Thanks John for doing this!
(comments imbedded)
On Wed, 16 Jan 2008, john stultz wrote:
On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
Completely un-tested, but it builds, so I figured I'd send it out for
review.
heh, ok, I'll take it and run it.
I'm not super sure the update
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
On Jan 16, 2008 6:56 AM, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
If you really want an seqlock free algorithm (I _do_ want
On Wed, 16 Jan 2008, Steven Rostedt wrote:
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
!0 is not necessarily 1. This is why I use cpu_synth-index ? 0 : 1 in
How about simply cpu_synth-index ^ 1? Seems the best choice if you ask
me, if all you are doing is changing it from 1 to zero and
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
+ int num = !cs-base_num;
+ cycle_t offset = (now - cs-base[!num].cycle_base_last);
!0 is not necessarily 1.
Incorrect.
!0 _is_ necessarily 1. It's how all C logical operators work. If you find
a compiler that turns !x into anything
* Linus Torvalds ([EMAIL PROTECTED]) wrote:
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
+ int num = !cs-base_num;
+ cycle_t offset = (now - cs-base[!num].cycle_base_last);
!0 is not necessarily 1.
Incorrect.
Hrm, *digging in my mailbox*, ah, here it is :
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
I would disable preemption in clocksource_get_basecycles. We would not
want to be scheduled out while we hold a pointer to the old array
element.
+ int num = cs-base_num;
Since you deal with base_num in a shared manner (not
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 14:36 -0800, john stultz wrote:
On Jan 16, 2008 6:56 AM, Mathieu Desnoyers [EMAIL PROTECTED] wrote:
If you really
On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
Thanks John for doing this!
(comments imbedded)
On Wed, 16 Jan 2008, john stultz wrote:
+ int num = !cs-base_num;
+ cycle_t offset = (now - cs-base[!num].cycle_base_last);
+ offset = cs-mask;
+ cs-base[num].cycle_base
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 18:39 -0500, Mathieu Desnoyers wrote:
I would disable preemption in clocksource_get_basecycles. We would not
want to be scheduled out while we hold a pointer to the old array
element.
+ int num = cs-base_num;
Since
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
Thanks John for doing this!
(comments imbedded)
On Wed, 16 Jan 2008, john stultz wrote:
+ int num = !cs-base_num;
+ cycle_t offset = (now - cs-base[!num].cycle_base_last);
+
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
Yep. clocksource_get_cycles() ended up not being as useful as an helper
function (I was hoping the arch vsyscall implementations could use it,
but they've done too much optimization - although that may reflect a
need up the chain to the
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
* john stultz ([EMAIL PROTECTED]) wrote:
On Wed, 2008-01-16 at 18:33 -0500, Steven Rostedt wrote:
Thanks John for doing this!
(comments imbedded)
On Wed, 16 Jan 2008, john stultz wrote:
+ int num = !cs-base_num;
+
On Wed, 16 Jan 2008, Mathieu Desnoyers wrote:
It would imply the creation of a new vsyscall : vgetschedperiod
It would read a counter that would increment each time the thread is
scheduled out (or in). It would be a per thread counter (not a per cpu
counter) so we can deal appropriately
Mathieu Desnoyers writes:
Sorry for self-reply, but I thought, in the past, of a way to make this
possible.
It would imply the creation of a new vsyscall : vgetschedperiod
It would read a counter that would increment each time the thread is
scheduled out (or in). It would be a per thread
On Thu, 17 Jan 2008, Paul Mackerras wrote:
It's very hard to do a per-thread counter in the VDSO, since threads
in the same process see the same memory, by definition. You'd have to
have an array of counters and have some way for each thread to know
which entry to read. Also you'd have to
* Paul Mackerras ([EMAIL PROTECTED]) wrote:
Mathieu Desnoyers writes:
Sorry for self-reply, but I thought, in the past, of a way to make this
possible.
It would imply the creation of a new vsyscall : vgetschedperiod
It would read a counter that would increment each time the thread
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
> On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
> >
> > Ok, but what actually insures that the clock->cycle_* reads won't be
> > reordered across the clocksource_read() ?
>
>
>
> Hmm, interesting.I didn't notice that clocksource_read() is a static
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
>
> Ok, but what actually insures that the clock->cycle_* reads won't be
> reordered across the clocksource_read() ?
Hmm, interesting.I didn't notice that clocksource_read() is a static
inline. I was thinking that since it was passing a pointer to
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
>
>
> On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
> > >
> > > Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> > > ---
> > > include/linux/clocksource.h |3 ++
> > > kernel/time/timekeeping.c | 48
> > >
On Tue, 15 Jan 2008, Steven Rostedt wrote:
>
> Also, it just occurred to me that this is an old patch. I thought I
> renamed cycle_raw to cycle_monotonic. But I must have lost that patch :-/
Ah, I changed this in the -rt patch queue, and never moved the patch back
here.
-- Steve
--
To
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
> >
> > Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>
> > ---
> > include/linux/clocksource.h |3 ++
> > kernel/time/timekeeping.c | 48
> >
> > 2 files changed, 51 insertions(+)
> >
> >
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> The latency tracer needs a way to get an accurate time
> without grabbing any locks. Locks themselves might call
> the latency tracer and cause at best a slow down.
>
> This patch adds get_monotonic_cycles that returns cycles
> from a reliable clock
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
The latency tracer needs a way to get an accurate time
without grabbing any locks. Locks themselves might call
the latency tracer and cause at best a slow down.
This patch adds get_monotonic_cycles that returns cycles
from a reliable clock source
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
include/linux/clocksource.h |3 ++
kernel/time/timekeeping.c | 48
2 files changed, 51 insertions(+)
Index:
On Tue, 15 Jan 2008, Steven Rostedt wrote:
Also, it just occurred to me that this is an old patch. I thought I
renamed cycle_raw to cycle_monotonic. But I must have lost that patch :-/
Ah, I changed this in the -rt patch queue, and never moved the patch back
here.
-- Steve
--
To unsubscribe
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
Signed-off-by: Steven Rostedt [EMAIL PROTECTED]
---
include/linux/clocksource.h |3 ++
kernel/time/timekeeping.c | 48
2 files
On Tue, 15 Jan 2008, Mathieu Desnoyers wrote:
Ok, but what actually insures that the clock-cycle_* reads won't be
reordered across the clocksource_read() ?
looks at code
Hmm, interesting.I didn't notice that clocksource_read() is a static
inline. I was thinking that since it was passing a
1 - 100 of 105 matches
Mail list logo
