All of lore.kernel.org
 help / color / mirror / Atom feed
From: Weng Meiling <wengmeiling.weng@huawei.com>
To: Will Deacon <will.deacon@arm.com>
Cc: Robert Richter <rric@kernel.org>,
	"oprofile-list@lists.sf.net" <oprofile-list@lists.sf.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Li Zefan <lizefan@huawei.com>,
	"wangnan0@huawei.com" <wangnan0@huawei.com>,
	"zhangwei(Jovi)" <jovi.zhangwei@huawei.com>,
	Huang Qiang <h.huangqiang@huawei.com>,
	"sdu.liu@huawei.com" <sdu.liu@huawei.com>
Subject: Re: [PATCH] oprofile: check whether oprofile perf enabled in op_overflow_handler()
Date: Sat, 15 Feb 2014 10:41:09 +0800	[thread overview]
Message-ID: <52FED3C5.1060703@huawei.com> (raw)
In-Reply-To: <20140211155207.GK8693@mudshark.cambridge.arm.com>

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 one? :) Thanks very much!

On 2014/2/11 23:52, Will Deacon wrote:
> On Tue, Feb 11, 2014 at 04:33:51AM +0000, 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
>>>>> adjusts the rate which might be worth being implemented for ARM too.
>>>>
>>>> Are you referring to the perf_sample_event_took callback? If so, that
>>>> certainly looks worth persuing. I'll stick it on my list, thanks!
>>>>
>>
>> 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?
> 
> Will
> 
> --->8
> 
> diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
> index 361a1aaee7c8..a6bc431cde70 100644
> --- a/arch/arm/kernel/perf_event.c
> +++ b/arch/arm/kernel/perf_event.c
> @@ -302,6 +302,8 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
>         struct arm_pmu *armpmu;
>         struct platform_device *plat_device;
>         struct arm_pmu_platdata *plat;
> +       int ret;
> +       u64 start_clock, finish_clock;
>  
>         if (irq_is_percpu(irq))
>                 dev = *(void **)dev;
> @@ -309,10 +311,15 @@ static irqreturn_t armpmu_dispatch_irq(int irq, void *dev)
>         plat_device = armpmu->plat_device;
>         plat = dev_get_platdata(&plat_device->dev);
>  
> +       start_clock = sched_clock();
>         if (plat && plat->handle_irq)
> -               return plat->handle_irq(irq, dev, armpmu->handle_irq);
> +               ret = plat->handle_irq(irq, dev, armpmu->handle_irq);
>         else
> -               return armpmu->handle_irq(irq, dev);
> +               ret = armpmu->handle_irq(irq, dev);
> +       finish_clock = sched_clock();
> +
> +       perf_sample_event_took(finish_clock - start_clock);
> +       return ret;
>  }
>  
>  static void
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 56003c6edfd3..6fcc293d77a4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -237,6 +237,8 @@ void perf_sample_event_took(u64 sample_len_ns)
>         u64 local_samples_len;
>         u64 allowed_ns = ACCESS_ONCE(perf_sample_allowed_ns);
>  
> +       pr_info("perf_sample_event_took(%llu ns)\n", sample_len_ns);
> +
>         if (allowed_ns == 0)
>                 return;
>  
>  
> 
> .
> 



  parent reply	other threads:[~2014-02-15  2:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-20  7:49 [PATCH] oprofile: check whether oprofile perf enabled in op_overflow_handler() Weng Meiling
2013-12-30  9:06 ` Weng Meiling
2014-01-13  8:45 ` Robert Richter
2014-01-14  1:52   ` Weng Meiling
2014-01-14 15:05     ` Robert Richter
2014-01-15  2:02       ` Weng Meiling
2014-01-15 10:24         ` Robert Richter
2014-01-16  1:09           ` Weng Meiling
2014-01-16  9:33             ` Weng Meiling
2014-01-16 11:52               ` Robert Richter
2014-01-16 19:36                 ` Will Deacon
2014-01-17  3:37                   ` Weng Meiling
2014-02-11  4:33                     ` Weng Meiling
2014-02-11 15:52                       ` Will Deacon
2014-02-11 18:05                         ` Will Deacon
2014-02-15  2:41                         ` Weng Meiling [this message]
2014-02-17 10:08                           ` Will Deacon
2014-02-17 11:39                             ` Weng Meiling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52FED3C5.1060703@huawei.com \
    --to=wengmeiling.weng@huawei.com \
    --cc=h.huangqiang@huawei.com \
    --cc=jovi.zhangwei@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=oprofile-list@lists.sf.net \
    --cc=rric@kernel.org \
    --cc=sdu.liu@huawei.com \
    --cc=wangnan0@huawei.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.