On Tue, Jan 06, 2015 at 11:18:39AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 05, 2015 at 03:23:38PM -0800, Shaohua Li wrote:
> > Good, it works. But the timestamp (.time_running and friends) only gets
> > updated for real hardware event between context switches. For software
> > event, the timesta
On Tue, Jan 06, 2015 at 11:18:39AM +0100, Peter Zijlstra wrote:
> On Mon, Jan 05, 2015 at 03:23:38PM -0800, Shaohua Li wrote:
> > Good, it works. But the timestamp (.time_running and friends) only gets
> > updated for real hardware event between context switches. For software
> > event, the timesta
On Mon, Jan 05, 2015 at 03:23:38PM -0800, Shaohua Li wrote:
> Good, it works. But the timestamp (.time_running and friends) only gets
> updated for real hardware event between context switches. For software
> event, the timestamp is initialized once, then never updated. If I use
> it to get time, I
On Fri, Jan 02, 2015 at 09:47:29AM -0800, Andy Lutomirski wrote:
> On Thu, Jan 1, 2015 at 6:59 PM, Shaohua Li wrote:
> > On Fri, Dec 19, 2014 at 06:03:34PM +0100, Peter Zijlstra wrote:
> >> On Fri, Dec 19, 2014 at 08:48:07AM -0800, Andy Lutomirski wrote:
> >> > On Fri, Dec 19, 2014 at 3:23 AM, Pet
On Thu, Jan 1, 2015 at 6:59 PM, Shaohua Li wrote:
> On Fri, Dec 19, 2014 at 06:03:34PM +0100, Peter Zijlstra wrote:
>> On Fri, Dec 19, 2014 at 08:48:07AM -0800, Andy Lutomirski wrote:
>> > On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra
>> > wrote:
>> > > On Thu, Dec 18, 2014 at 04:22:59PM -0800
On 1/2/15 10:17 AM, Shaohua Li wrote:
On Fri, Jan 02, 2015 at 10:09:10AM -0700, David Ahern wrote:
On 1/2/15 10:02 AM, Shaohua Li wrote:
On Fri, Jan 02, 2015 at 08:31:33AM -0700, David Ahern wrote:
On 1/1/15 7:59 PM, Shaohua Li wrote:
I'm wondering how we could use the perf to implament a clo
On Fri, Jan 02, 2015 at 10:09:10AM -0700, David Ahern wrote:
> On 1/2/15 10:02 AM, Shaohua Li wrote:
> >On Fri, Jan 02, 2015 at 08:31:33AM -0700, David Ahern wrote:
> >>On 1/1/15 7:59 PM, Shaohua Li wrote:
> >>>I'm wondering how we could use the perf to implament a clock_gettime.
> >>>reading the p
On 1/2/15 10:02 AM, Shaohua Li wrote:
On Fri, Jan 02, 2015 at 08:31:33AM -0700, David Ahern wrote:
On 1/1/15 7:59 PM, Shaohua Li wrote:
I'm wondering how we could use the perf to implament a clock_gettime.
reading the perf fd or using ioctl is slow so reading the mmap
ringbuffer is the only opt
On Fri, Jan 02, 2015 at 08:31:33AM -0700, David Ahern wrote:
> On 1/1/15 7:59 PM, Shaohua Li wrote:
> >I'm wondering how we could use the perf to implament a clock_gettime.
> >reading the perf fd or using ioctl is slow so reading the mmap
> >ringbuffer is the only option. But as far as I know the r
On 1/1/15 7:59 PM, Shaohua Li wrote:
I'm wondering how we could use the perf to implament a clock_gettime.
reading the perf fd or using ioctl is slow so reading the mmap
ringbuffer is the only option. But as far as I know the ringbuffer has
data only when an event is generated. Between two events
On Fri, Dec 19, 2014 at 06:03:34PM +0100, Peter Zijlstra wrote:
> On Fri, Dec 19, 2014 at 08:48:07AM -0800, Andy Lutomirski wrote:
> > On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra
> > wrote:
> > > On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
> > >> Bad news: this patch is i
On Fri, Dec 19, 2014 at 09:53:24AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 19, 2014 at 9:42 AM, Chris Mason wrote:
> >
> >
> > On Fri, Dec 19, 2014 at 11:48 AM, Andy Lutomirski
> > wrote:
> >>
> >> On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra
> >> wrote:
> >>>
> >>> On Thu, Dec 18, 2014
On Fri, Dec 19, 2014 at 9:42 AM, Chris Mason wrote:
>
>
> On Fri, Dec 19, 2014 at 11:48 AM, Andy Lutomirski
> wrote:
>>
>> On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra
>> wrote:
>>>
>>> On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
Bad news: this patch is incorr
On Fri, Dec 19, 2014 at 9:27 AM, Peter Zijlstra wrote:
> On Fri, Dec 19, 2014 at 09:07:49AM -0800, Andy Lutomirski wrote:
>> Re-asking my old question: would it make sense to add a vdso helper
>> for the magic self-monitoring interface? Or, at the very least, we
>> could try to tidy up the docs a
On Fri, Dec 19, 2014 at 11:48 AM, Andy Lutomirski
wrote:
On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra
wrote:
On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
Bad news: this patch is incorrect, I think. Take a look at
update_rq_clock -- it does fancy things involving
On Fri, Dec 19, 2014 at 09:07:49AM -0800, Andy Lutomirski wrote:
> Re-asking my old question: would it make sense to add a vdso helper
> for the magic self-monitoring interface? Or, at the very least, we
> could try to tidy up the docs a bit.
I find it really helps (performance wise) to strip dow
On Fri, Dec 19, 2014 at 9:03 AM, Peter Zijlstra wrote:
> On Fri, Dec 19, 2014 at 08:48:07AM -0800, Andy Lutomirski wrote:
>> On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra wrote:
>> > On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
>> >> Bad news: this patch is incorrect, I thin
On Fri, Dec 19, 2014 at 08:48:07AM -0800, Andy Lutomirski wrote:
> On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra wrote:
> > On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
> >> Bad news: this patch is incorrect, I think. Take a look at
> >> update_rq_clock -- it does fancy thin
On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra wrote:
> On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
>> Bad news: this patch is incorrect, I think. Take a look at
>> update_rq_clock -- it does fancy things involving irq time and
>> paravirt steal time. So this patch could re
On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
> Bad news: this patch is incorrect, I think. Take a look at
> update_rq_clock -- it does fancy things involving irq time and
> paravirt steal time. So this patch could result in extremely
> non-monotonic results.
Yeah, I'm not sur
On Thu, 18 Dec 2014, Shaohua Li wrote:
> On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
> > Bad news: this patch is incorrect, I think. Take a look at
> > update_rq_clock -- it does fancy things involving irq time and
> > paravirt steal time. So this patch could result in extrem
On Thu, Dec 18, 2014 at 4:30 PM, Shaohua Li wrote:
> On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
>> On Thu, Dec 18, 2014 at 3:30 PM, Andy Lutomirski wrote:
>> > On Wed, Dec 17, 2014 at 3:12 PM, Shaohua Li wrote:
>> >> This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTI
On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 18, 2014 at 3:30 PM, Andy Lutomirski wrote:
> > On Wed, Dec 17, 2014 at 3:12 PM, Shaohua Li wrote:
> >> This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We
> >> use the following method to compute t
On Thu, Dec 18, 2014 at 3:30 PM, Andy Lutomirski wrote:
> On Wed, Dec 17, 2014 at 3:12 PM, Shaohua Li wrote:
>> This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We
>> use the following method to compute the thread cpu time:
>>
>> t0 = process start
>> t1 = most recent
On Wed, Dec 17, 2014 at 3:12 PM, Shaohua Li wrote:
> This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We
> use the following method to compute the thread cpu time:
>
> t0 = process start
> t1 = most recent context switch time
> t2 = time at which the vsyscall is inv
This primarily speeds up clock_gettime(CLOCK_THREAD_CPUTIME_ID, ..). We
use the following method to compute the thread cpu time:
t0 = process start
t1 = most recent context switch time
t2 = time at which the vsyscall is invoked
thread_cpu_time = sum(time slices between t0 to t1) +
26 matches
Mail list logo
