On Tue, 2014-07-22 at 20:39 +0100, Richard Cochran wrote:
> So the only reasonable way, IMHO, is to simply provide the needed
> information in the traces, and then add some user space code to find
> the relationship between the perf clock and the system clock. The
> great advantage of this approach
On Tue, Jul 22, 2014 at 05:17:29PM +0100, Pawel Moll wrote:
> That approach has been also discussed, last time in the mentioned
> thread:
>
> http://thread.gmane.org/gmane.linux.kernel/1611683/focus=1612554
> http://thread.gmane.org/gmane.linux.kernel/1611683/focus=1612554
>
> With both Ingo and
On Tue, 2014-07-22 at 17:34 +0100, Peter Zijlstra wrote:
> On Tue, Jul 22, 2014 at 05:17:29PM +0100, Pawel Moll wrote:
> > With both Ingo and John showing preference towards the clock alignment,
> > so that's where I looked this time (I've already done custom perf
> > ioctls, posix clocks... don't
On Tue, Jul 22, 2014 at 05:17:29PM +0100, Pawel Moll wrote:
> With both Ingo and John showing preference towards the clock alignment,
> so that's where I looked this time (I've already done custom perf
> ioctls, posix clocks... don't really know how many different ways I've
> tried).
So we should
On Tue, Jul 22, 2014 at 05:17:23PM +0100, Pawel Moll wrote:
> > Now, I already mentioned max error bounds, and I've not yet looked at
> > your actual control loop, but that is something to keep in mind, we want
> > something that's limited.
>
> Indeed. Richard has already expressed concerns that m
On Sat, 2014-07-19 at 06:02 +0100, Richard Cochran wrote:
> On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote:
> >
> > This code definitely needs more work and testing (I'm not 100%
> > sure if the Kp and Ki I've picked for the proportional and
> > integral terms are universal),
>
> I wo
On Fri, 2014-07-18 at 20:34 +0100, Peter Zijlstra wrote:
> On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> > Also, assuming we someday will merge the x86 sched_clock logic into
> > the generic sched_clock code, we'll have to handle cases where they
> > aren't the same.
>
> I prefer
On Fri, 2014-07-18 at 23:41 +0100, Peter Zijlstra wrote:
> So something that might be usable for all of us would be the
> 'abstracted' control loop.
>
> So the problem is, given a Set Point (CLOCK_MONOTONIC_RAW), a Process
> Variable (sched_clock) compute a Control Output (multiplier).
>
> If tha
On Fri, 2014-07-18 at 18:51 +0100, John Stultz wrote:
> Very cool work!
Glad that it doesn't sound too ridiculous :-)
> I've not been able to review it carefully, but one good
> stress test would be to pick a system where the hardware used for
> sched_clock is different from the hardware used fo
On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote:
>
> This code definitely needs more work and testing (I'm not 100%
> sure if the Kp and Ki I've picked for the proportional and
> integral terms are universal),
I wouldn't bet on it.
> but for now wanted to see
> if this approach makes
On Fri, Jul 18, 2014 at 10:22:50PM +0200, Peter Zijlstra wrote:
> So the generic stuff seems optimized for 32bit arch, short clocks and
> seems to hard assume the clock is globally consistent.
>
> The x86 sched_clock code is optimized for 64bit, has a full 64bit clock
> and cannot ever assume the
On Fri, Jul 18, 2014 at 12:46:29PM -0700, John Stultz wrote:
> On 07/18/2014 12:34 PM, Peter Zijlstra wrote:
> > On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> >> Also, assuming we someday will merge the x86 sched_clock logic into
> >> the generic sched_clock code, we'll have to han
On 07/18/2014 12:34 PM, Peter Zijlstra wrote:
> On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
>> Also, assuming we someday will merge the x86 sched_clock logic into
>> the generic sched_clock code, we'll have to handle cases where they
>> aren't the same.
> I prefer that to not happe
On Fri, Jul 18, 2014 at 12:25:48PM -0700, John Stultz wrote:
> Also, assuming we someday will merge the x86 sched_clock logic into
> the generic sched_clock code, we'll have to handle cases where they
> aren't the same.
I prefer that to not happen. I spend quite a bit of time and effort to
make th
On Fri, Jul 18, 2014 at 12:13 PM, Peter Zijlstra wrote:
> On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote:
>> This change is trying to make the sched clock "similar" to the
>> monotonic raw one.
>>
>> The main goal is to provide some kind of unification between time
>> flow in kernel an
On Fri, Jul 18, 2014 at 06:43:39PM +0100, Pawel Moll wrote:
> This change is trying to make the sched clock "similar" to the
> monotonic raw one.
>
> The main goal is to provide some kind of unification between time
> flow in kernel and in user space, mainly to achieve correlation
> between perf t
On Fri, Jul 18, 2014 at 10:51:19AM -0700, John Stultz wrote:
> Very cool work! I've not been able to review it carefully, but one good
> stress test would be to pick a system where the hardware used for
> sched_clock is different from the hardware used for timekeeping.
>
> Probably easily done on
On 07/18/2014 10:43 AM, Pawel Moll wrote:
> This change is trying to make the sched clock "similar" to the
> monotonic raw one.
>
> The main goal is to provide some kind of unification between time
> flow in kernel and in user space, mainly to achieve correlation
> between perf timestamps and clock
This change is trying to make the sched clock "similar" to the
monotonic raw one.
The main goal is to provide some kind of unification between time
flow in kernel and in user space, mainly to achieve correlation
between perf timestamps and clock_gettime(CLOCK_MONOTONIC_RAW).
This has been suggeste
19 matches
Mail list logo
