On 1/9/14, 8:19 AM, Frederic Weisbecker wrote:
On Wed, Jan 08, 2014 at 02:48:37PM -0700, David Ahern wrote:
The existing code does not work. Your unstable tsc patch did not
work. I have not tried Joseph's patch. Are you proposing that one or
do you have something else in mind?
I think we shoul
On Wed, Jan 08, 2014 at 02:48:37PM -0700, David Ahern wrote:
> The existing code does not work. Your unstable tsc patch did not
> work. I have not tried Joseph's patch. Are you proposing that one or
> do you have something else in mind?
I think we should integrate Joseph's patch (or mine, or some
On 1/4/14, 8:05 AM, Frederic Weisbecker wrote:
On Fri, Jan 03, 2014 at 03:45:36PM -0700, David Ahern wrote:
On 1/3/14, 3:07 PM, Frederic Weisbecker wrote:
I'm not sure I understand why we need that. Why doesn't it work by simply
flushing
events prior to the earliest timestamp among every CPUs
On Fri, Jan 03, 2014 at 03:45:36PM -0700, David Ahern wrote:
> On 1/3/14, 3:07 PM, Frederic Weisbecker wrote:
> >I'm not sure I understand why we need that. Why doesn't it work by simply
> >flushing
> >events prior to the earliest timestamp among every CPUs last event?
>
> Here's one scenario. Co
On 1/3/14, 3:07 PM, Frederic Weisbecker wrote:
On Wed, Jan 01, 2014 at 11:37:55AM -0700, David Ahern wrote:
On 12/26/13, 8:30 AM, Frederic Weisbecker wrote:
On Thu, Dec 26, 2013 at 10:24:03AM -0500, David Ahern wrote:
On 12/26/13, 10:14 AM, Frederic Weisbecker wrote:
I was carrying that patch
On Wed, Jan 01, 2014 at 11:37:55AM -0700, David Ahern wrote:
> On 12/26/13, 8:30 AM, Frederic Weisbecker wrote:
> >On Thu, Dec 26, 2013 at 10:24:03AM -0500, David Ahern wrote:
> >>On 12/26/13, 10:14 AM, Frederic Weisbecker wrote:
> I was carrying that patch while working on perf-kvm-stat-live l
On 12/26/13, 8:30 AM, Frederic Weisbecker wrote:
On Thu, Dec 26, 2013 at 10:24:03AM -0500, David Ahern wrote:
On 12/26/13, 10:14 AM, Frederic Weisbecker wrote:
I was carrying that patch while working on perf-kvm-stat-live last
Fall. It does not solve the problem for live commands, so ended up
d
On Thu, Dec 26, 2013 at 10:24:03AM -0500, David Ahern wrote:
> On 12/26/13, 10:14 AM, Frederic Weisbecker wrote:
> >>I was carrying that patch while working on perf-kvm-stat-live last
> >>Fall. It does not solve the problem for live commands, so ended up
> >>dropping it and going with local (to the
On 12/26/13, 10:14 AM, Frederic Weisbecker wrote:
I was carrying that patch while working on perf-kvm-stat-live last
Fall. It does not solve the problem for live commands, so ended up
dropping it and going with local (to the command) hacks. I still
think for live commands getting a perf_clock tim
On Mon, Dec 23, 2013 at 09:44:25AM -0500, David Ahern wrote:
> On 12/23/13, 8:10 AM, Frederic Weisbecker wrote:
> >On Fri, Dec 20, 2013 at 10:09:53AM -0700, David Ahern wrote:
> >>On 12/20/13, 5:27 AM, Joseph Schuchart wrote:
> >>>I know this comes late, but: As far as I can see, your change does n
On 12/23/13, 8:10 AM, Frederic Weisbecker wrote:
On Fri, Dec 20, 2013 at 10:09:53AM -0700, David Ahern wrote:
On 12/20/13, 5:27 AM, Joseph Schuchart wrote:
I know this comes late, but: As far as I can see, your change does not
preserve the logic of the code I suggested. The idea was to first ga
On Fri, Dec 20, 2013 at 10:09:53AM -0700, David Ahern wrote:
> On 12/20/13, 5:27 AM, Joseph Schuchart wrote:
> >I know this comes late, but: As far as I can see, your change does not
> >preserve the logic of the code I suggested. The idea was to first gather
> >all the maximum timestamps of all cpu
On 12/20/13, 5:27 AM, Joseph Schuchart wrote:
I know this comes late, but: As far as I can see, your change does not
preserve the logic of the code I suggested. The idea was to first gather
all the maximum timestamps of all cpus (that is, the last timestamp seen
on each cpu) and then determine th
On 27.11.2013 14:51, Ingo Molnar wrote:
>
> * Joseph Schuchart wrote:
>
>> Sorry for my delayed reply, it's been a busy week and I really wanted to
>> give Ingo's idea below some thought. Please find my comments below.
>>
> If done that way then AFAICS we could even eliminate the
> ->
* Joseph Schuchart wrote:
> Sorry for my delayed reply, it's been a busy week and I really wanted to
> give Ingo's idea below some thought. Please find my comments below.
>
> >>> If done that way then AFAICS we could even eliminate the
> >>> ->max_timestamps[NR_CPUS] array.
> >>
> >> I can und
On Thu, Nov 14, 2013 at 08:02:48AM -0700, David Ahern wrote:
> On 11/14/13, 7:44 AM, Peter Zijlstra wrote:
> >On Thu, Nov 14, 2013 at 07:26:06AM -0700, David Ahern wrote:
> >>On 11/14/13, 3:05 AM, Ingo Molnar wrote:
> >>
> >>>What am I missing?
> >>
> >>I have spent quite a bit of time on this prob
On 11/14/13, 7:44 AM, Peter Zijlstra wrote:
On Thu, Nov 14, 2013 at 07:26:06AM -0700, David Ahern wrote:
On 11/14/13, 3:05 AM, Ingo Molnar wrote:
What am I missing?
I have spent quite a bit of time on this problem on this well. I think the
flush time needs to be based on the start time of ea
On Thu, Nov 14, 2013 at 07:26:06AM -0700, David Ahern wrote:
> On 11/14/13, 3:05 AM, Ingo Molnar wrote:
>
> >What am I missing?
>
> I have spent quite a bit of time on this problem on this well. I think the
> flush time needs to be based on the start time of each round, not the
> minimum time obs
On 11/14/13, 3:05 AM, Ingo Molnar wrote:
What am I missing?
I have spent quite a bit of time on this problem on this well. I think
the flush time needs to be based on the start time of each round, not
the minimum time observed across mmaps. I have tried the minimum time
stamp route and it s
* Joseph Schuchart wrote:
> > Just a quick side note, while I realize that you are
> > (rightfully!) concerned about correctness primarily, if that loop
> > over MAX_NR_CPUS executes often enough then this might hurt
> > performance:
> >
> >perf.h:#define MAX_NR_CPUS
> Just a quick side note, while I realize that you are
> (rightfully!) concerned about correctness primarily, if that loop
> over MAX_NR_CPUS executes often enough then this might hurt
> performance:
>
>perf.h:#define MAX_NR_CPUS 256
>
> So it might be better to mainta
* Joseph Schuchart wrote:
> @@ -549,15 +552,24 @@ static int flush_sample_queue(struct perf_session *s,
> return 0;
> }
>
> +static inline void set_next_flush(struct perf_session *session)
> +{
> + int i;
> + u64 min_max_timestamp = session->ordered_samples.max_timestamps[0];
>
Good morning,
We came across a problem in perf script which causes it to abort reading
a file produced with perf record, complaining about timestamps being
earlier than the last flushed timeslice. ("Warning: Timestamp below last
timeslice flush")
While investigating the issue, we found that the a
23 matches
Mail list logo
