On 2014/2/17 18:08, Will Deacon wrote:
> On Sat, Feb 15, 2014 at 02:41:09AM +, Weng Meiling wrote:
>> Hi Will,
>>
>> I test kernel with this patch, the problem has be fixed. When the
>> event's sample_period is small, the cpu will not stall except printing
>> warning "oprofile: ignoring
On Sat, Feb 15, 2014 at 02:41:09AM +, Weng Meiling wrote:
> Hi Will,
>
> I test kernel with this patch, the problem has be fixed. When the
> event's sample_period is small, the cpu will not stall except printing
> warning "oprofile: ignoring spurious overflow ignoring spurious overflow".
>
On Sat, Feb 15, 2014 at 02:41:09AM +, Weng Meiling wrote:
Hi Will,
I test kernel with this patch, the problem has be fixed. When the
event's sample_period is small, the cpu will not stall except printing
warning oprofile: ignoring spurious overflow ignoring spurious overflow.
This
On 2014/2/17 18:08, Will Deacon wrote:
On Sat, Feb 15, 2014 at 02:41:09AM +, Weng Meiling wrote:
Hi Will,
I test kernel with this patch, the problem has be fixed. When the
event's sample_period is small, the cpu will not stall except printing
warning oprofile: ignoring spurious
Hi Will,
I test kernel with this patch, the problem has be fixed. When the
event's sample_period is small, the cpu will not stall except printing
warning "oprofile: ignoring spurious overflow ignoring spurious overflow".
This is normal for unregistered event.
So would you please send a
Hi Will,
I test kernel with this patch, the problem has be fixed. When the
event's sample_period is small, the cpu will not stall except printing
warning oprofile: ignoring spurious overflow ignoring spurious overflow.
This is normal for unregistered event.
So would you please send a formal
On Tue, Feb 11, 2014 at 03:52:07PM +, Will Deacon wrote:
> On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
> > Is there any progress on this work? Because this is important for me.
> > Sorry for trouble you.
>
> Oops, I totally forgot about this. Does the below patch work for
On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
> Hi Will,
Hello,
> >>> how userland can be notified about throttling. Throttling could be
> >>> worth for operf too, not only for the oprofile kernel driver.
> >>>
> >
> >>> From a quick look it seems there is also code in x86 that
On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
Hi Will,
Hello,
how userland can be notified about throttling. Throttling could be
worth for operf too, not only for the oprofile kernel driver.
From a quick look it seems there is also code in x86 that dynamically
On Tue, Feb 11, 2014 at 03:52:07PM +, Will Deacon wrote:
On Tue, Feb 11, 2014 at 04:33:51AM +, Weng Meiling wrote:
Is there any progress on this work? Because this is important for me.
Sorry for trouble you.
Oops, I totally forgot about this. Does the below patch work for you?
Hi Will,
>
>>> how userland can be notified about throttling. Throttling could be
>>> worth for operf too, not only for the oprofile kernel driver.
>>>
>
>>> From a quick look it seems there is also code in x86 that dynamically
>>> adjusts the rate which might be worth being implemented for ARM
Hi Will,
how userland can be notified about throttling. Throttling could be
worth for operf too, not only for the oprofile kernel driver.
From a quick look it seems there is also code in x86 that dynamically
adjusts the rate which might be worth being implemented for ARM too.
Are you
On 2014/1/17 3:36, Will Deacon wrote:
> On Thu, Jan 16, 2014 at 11:52:45AM +, Robert Richter wrote:
>> (cc'ing Will)
>
> Thanks Robert,
>
>> The problem of too low sample periods could be solved on ARM by using
>> perf's interrupt throttling, you might play around with:
>>
>>
On Thu, Jan 16, 2014 at 11:52:45AM +, Robert Richter wrote:
> (cc'ing Will)
Thanks Robert,
> On 16.01.14 17:33:04, Weng Meiling wrote:
> > Using the same test case, the problem also exists in the same kernel with
> > the new patch applied:
> >
> >
> > # opcontrol --start
> >
> > Using
(cc'ing Will)
Weng,
thanks for testing.
On 16.01.14 17:33:04, Weng Meiling wrote:
> Using the same test case, the problem also exists in the same kernel with the
> new patch applied:
>
>
> # opcontrol --start
>
> Using 2.6+ OProfile kernel interface.
> Using log file
Hi Robert,
The testcase which trigger the problem on kernel 2.6.34 is:
opcontrol --init
opcontrol --no-vmlinux
opcontrol --event=CPU_CYCLES:500:0:1:1
opcontrol --start
Run the testcase in the Linux 3.13-rc1 kernel, the last step "opcontrol --start"
will stall, and can't be killed, and print the
Hi Robert,
The testcase which trigger the problem on kernel 2.6.34 is:
opcontrol --init
opcontrol --no-vmlinux
opcontrol --event=CPU_CYCLES:500:0:1:1
opcontrol --start
Run the testcase in the Linux 3.13-rc1 kernel, the last step opcontrol --start
will stall, and can't be killed, and print the
(cc'ing Will)
Weng,
thanks for testing.
On 16.01.14 17:33:04, Weng Meiling wrote:
Using the same test case, the problem also exists in the same kernel with the
new patch applied:
# opcontrol --start
Using 2.6+ OProfile kernel interface.
Using log file
On Thu, Jan 16, 2014 at 11:52:45AM +, Robert Richter wrote:
(cc'ing Will)
Thanks Robert,
On 16.01.14 17:33:04, Weng Meiling wrote:
Using the same test case, the problem also exists in the same kernel with
the new patch applied:
# opcontrol --start
Using 2.6+ OProfile
On 2014/1/17 3:36, Will Deacon wrote:
On Thu, Jan 16, 2014 at 11:52:45AM +, Robert Richter wrote:
(cc'ing Will)
Thanks Robert,
The problem of too low sample periods could be solved on ARM by using
perf's interrupt throttling, you might play around with:
On 2014/1/15 18:24, Robert Richter wrote:
> On 15.01.14 10:02:44, Weng Meiling wrote:
>> On 2014/1/14 23:05, Robert Richter wrote:
>>> @@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
>>>
>>> per_cpu(perf_events, cpu)[event] = pevent;
>>>
>>> + /* sync perf_events
On 15.01.14 10:02:44, Weng Meiling wrote:
> On 2014/1/14 23:05, Robert Richter wrote:
> > @@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
> >
> > per_cpu(perf_events, cpu)[event] = pevent;
> >
> > + /* sync perf_events with overflow handler: */
> > + smp_wmb();
> >
On 15.01.14 10:02:44, Weng Meiling wrote:
On 2014/1/14 23:05, Robert Richter wrote:
@@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
per_cpu(perf_events, cpu)[event] = pevent;
+ /* sync perf_events with overflow handler: */
+ smp_wmb();
+
+
On 2014/1/15 18:24, Robert Richter wrote:
On 15.01.14 10:02:44, Weng Meiling wrote:
On 2014/1/14 23:05, Robert Richter wrote:
@@ -94,6 +98,11 @@ static int op_create_counter(int cpu, int event)
per_cpu(perf_events, cpu)[event] = pevent;
+ /* sync perf_events with overflow
On 2014/1/14 23:05, Robert Richter wrote:
> On 14.01.14 09:52:11, Weng Meiling wrote:
>> On 2014/1/13 16:45, Robert Richter wrote:
>>> On 20.12.13 15:49:01, Weng Meiling wrote:
>
The problem was once triggered on kernel 2.6.34, the main information:
<3>BUG: soft lockup - CPU#0 stuck for
On 14.01.14 09:52:11, Weng Meiling wrote:
> On 2014/1/13 16:45, Robert Richter wrote:
> > On 20.12.13 15:49:01, Weng Meiling wrote:
> >> The problem was once triggered on kernel 2.6.34, the main information:
> >> <3>BUG: soft lockup - CPU#0 stuck for 60005ms! [opcontrol:8673]
> >>
> >> Pid: 8673,
On 14.01.14 09:52:11, Weng Meiling wrote:
On 2014/1/13 16:45, Robert Richter wrote:
On 20.12.13 15:49:01, Weng Meiling wrote:
The problem was once triggered on kernel 2.6.34, the main information:
3BUG: soft lockup - CPU#0 stuck for 60005ms! [opcontrol:8673]
Pid: 8673, comm:
On 2014/1/14 23:05, Robert Richter wrote:
On 14.01.14 09:52:11, Weng Meiling wrote:
On 2014/1/13 16:45, Robert Richter wrote:
On 20.12.13 15:49:01, Weng Meiling wrote:
The problem was once triggered on kernel 2.6.34, the main information:
3BUG: soft lockup - CPU#0 stuck for 60005ms!
On 2014/1/13 16:45, Robert Richter wrote:
> Weng,
>
> sorry for answering late, your mail hit the holiday season.
>
> On 20.12.13 15:49:01, Weng Meiling wrote:
>>
>> From: Weng Meiling
>>
>> There is a situation event is triggered before oprofile_perf_start() finish.
>> Because the event is
Weng,
sorry for answering late, your mail hit the holiday season.
On 20.12.13 15:49:01, Weng Meiling wrote:
>
> From: Weng Meiling
>
> There is a situation event is triggered before oprofile_perf_start() finish.
> Because the event is still not stored in per_cpu(perf_events, cpu)[event],
>
Weng,
sorry for answering late, your mail hit the holiday season.
On 20.12.13 15:49:01, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in
On 2014/1/13 16:45, Robert Richter wrote:
Weng,
sorry for answering late, your mail hit the holiday season.
On 20.12.13 15:49:01, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the
Hi Robert,
What do you think about this patch?
On 2013/12/20 15:49, Weng Meiling wrote:
>
> From: Weng Meiling
>
> There is a situation event is triggered before oprofile_perf_start() finish.
> Because the event is still not stored in per_cpu(perf_events, cpu)[event],
> op_overflow_handler()
Hi Robert,
What do you think about this patch?
On 2013/12/20 15:49, Weng Meiling wrote:
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
From: Weng Meiling
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
op_overflow_handler() will print the warning. During the time, if unregistered
event is triggered again, the cpu will print
From: Weng Meiling wengmeiling.w...@huawei.com
There is a situation event is triggered before oprofile_perf_start() finish.
Because the event is still not stored in per_cpu(perf_events, cpu)[event],
op_overflow_handler() will print the warning. During the time, if unregistered
event is triggered
36 matches
Mail list logo
