From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
> The problem is that users have to wait tens of minutes to see perf
> top results on the screen in KNL. Before that, there is nothing but
> a black screen.
I'm actually curious why so I started digging last night.
First, I made perf top
On 10/29/2018 6:42 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
- struct annotation_options *annotation_options
__maybe_unused)
+ struct annotation_options *annotation_options __maybe_unused,
+
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 18:32:40 -0400
> - struct annotation_options *annotation_options
> __maybe_unused)
> + struct annotation_options *annotation_options __maybe_unused,
> + atomic_t *nr_rb_read __maybe_unused)
> {
There is no problem with the message, the problem is the thread where
the message is being displayed, just signal the display thread to
display the warning, not doing that in the event processing thread.
How about this patch (just did some simple test)? It moves the warning
to display thr
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 14:20:15 -0400
> You didn't see any warning before the patch. I think it is just
> because perf top hides the problem.
Quite honestly, the last time I played around with this:
1) The new ring buffer mode didn't exist
2) perf started up much more quickl
Em Mon, Oct 29, 2018 at 02:20:15PM -0400, Liang, Kan escreveu:
>
>
> On 10/29/2018 1:48 PM, David Miller wrote:
> > From: "Liang, Kan"
> > Date: Mon, 29 Oct 2018 13:42:56 -0400
> >
> > >
> > >
> > > On 10/29/2018 1:40 PM, David Miller wrote:
> > > > From: "Liang, Kan"
> > > > Date: Mon, 29 O
On 10/29/2018 1:48 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 13:42:56 -0400
On 10/29/2018 1:40 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
I just realized that the problem in KNL will be back if we switch
back to non-overwri
Em Mon, Oct 29, 2018 at 10:43:21AM -0700, David Miller escreveu:
> From: "Liang, Kan"
> Date: Mon, 29 Oct 2018 11:11:25 -0400
>
> > The processing time for each perf_top__mmap_read_idx() should not that
> > long. We may check it after each perf_top__mmap_read_idx(). Also
> > change the ui_warning
Em Mon, Oct 29, 2018 at 10:40:08AM -0700, David Miller escreveu:
> From: "Liang, Kan"
> Date: Mon, 29 Oct 2018 10:33:06 -0400
>
> > I just realized that the problem in KNL will be back if we switch
> > back to non-overwrite mode.
>
>> What is KNL?
I guess its Knights Landing.
https://en.wikipe
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 13:42:56 -0400
>
>
> On 10/29/2018 1:40 PM, David Miller wrote:
>> From: "Liang, Kan"
>> Date: Mon, 29 Oct 2018 10:33:06 -0400
>>
>>> I just realized that the problem in KNL will be back if we switch
>>> back to non-overwrite mode.
>> What is KNL?
>>
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 11:11:25 -0400
> The processing time for each perf_top__mmap_read_idx() should not that
> long. We may check it after each perf_top__mmap_read_idx(). Also
> change the ui_warning to one-time warning. The patch as below can do
> that (not test).
You canno
On 10/29/2018 1:40 PM, David Miller wrote:
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
I just realized that the problem in KNL will be back if we switch
back to non-overwrite mode.
What is KNL?
Intel Xeon Phi Processor, Knights Landing.
Thanks,
Kan
From: "Liang, Kan"
Date: Mon, 29 Oct 2018 10:33:06 -0400
> I just realized that the problem in KNL will be back if we switch
> back to non-overwrite mode.
What is KNL?
On 10/29/2018 10:35 AM, Arnaldo Carvalho de Melo wrote:
Em Mon, Oct 29, 2018 at 10:33:06AM -0400, Liang, Kan escreveu:
On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Mon, Oct 29, 2018 at 10:33:06AM -0400, Liang, Kan escreveu:
> On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, L
On 10/29/2018 9:03 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
> On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018 at 03:07:40PM -0400, L
Em Fri, Oct 26, 2018 at 04:11:51PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
> > >
> > >
> > > On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > > > Em Fri, Oct 26, 2018 at
On 10/26/2018 3:24 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote
Em Fri, Oct 26, 2018 at 03:16:29PM -0400, Liang, Kan escreveu:
>
>
> On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> > > On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > > > So, I'm adding the following to my tr
On 10/26/2018 3:12 PM, Arnaldo Carvalho de Melo wrote:
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can
Em Fri, Oct 26, 2018 at 03:07:40PM -0400, Liang, Kan escreveu:
> On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
> > So, I'm adding the following to my tree to help in diagnosing problems
> > with this overwrite mode:
> Actually, you can use per-event overwrite term to disable overwrite mo
On 10/26/2018 3:02 PM, Arnaldo Carvalho de Melo wrote:
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
Actually, you can use per-event overwrite term to disable overwrite mode
for perf top.
/*
* Check per-event overwrite term.
* perf top
So, I'm adding the following to my tree to help in diagnosing problems
with this overwrite mode:
>From 40feb09001c7cc2ba8aeaa0a8f03b6d28fa4ca95 Mon Sep 17 00:00:00 2001
From: Arnaldo Carvalho de Melo
Date: Fri, 26 Oct 2018 15:55:23 -0300
Subject: [PATCH 1/1] perf top: Allow disabling the overwri
Em Fri, Oct 26, 2018 at 03:38:05PM -0300, Arnaldo Carvalho de Melo escreveu:
> Addind a few folks to the CC list, Wang implemented the backwards ring
> buffer code.
Adding a few more, since the patch switching 'perf top' to overwrite
mode and the motivation for doing so is this one:
commit ebebbf
Addind a few folks to the CC list, Wang implemented the backwards ring
buffer code.
Em Fri, Oct 26, 2018 at 10:45:13AM -0700, David Miller escreveu:
> Since the last time I looked deeply into perf I notice that
> perf top now uses a new ring buffer mode by default.
>
> Basically, events are writt
Since the last time I looked deeply into perf I notice that
perf top now uses a new ring buffer mode by default.
Basically, events are written in reverse order, and when fetching
events the tool uses an ioctl to "pause" the ring buffer.
I understand some of the reasons for pursing this kind of
27 matches
Mail list logo
