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 spur
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".
>
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 forma
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
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 d
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
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:
>>
>> /proc/sys/kerne
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
(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 /var/lib/oprofile/sample
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 f
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
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/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 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 stil
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],
> op_
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() wi
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 a
18 matches
Mail list logo
