Re: possible lock issue on Oprofile

On 04/27/2012 03:15 PM, Breno Leitao wrote:
> Hi,
> 
> I was just running oprofile with lock dependency enabled and I get the
> following message, on a Power 730 with RHEL6.2.

Robert, does any of this look familiar to you?

-Maynard
> 
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-257.el6.ppc64.debug-breno #2
> -------------------------------------------------------
> oprofiled/21117 is trying to acquire lock:
>  (buffer_mutex){+.+...}, at: [<d00000000f531678>] .sync_buffer+0x68/0x620
> [oprofile]
> 
> but task is already holding lock:
>  ((task_exit_notifier).rwsem){++++..}, at: [<c0000000000c88e4>]
> .__blocking_notifier_call_chain+0x44/0x90
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #1 ((task_exit_notifier).rwsem){++++..}:
>        [<c0000000000dfa84>] .lock_acquire+0xb4/0x160
>        [<c0000000005e1b94>] .down_write+0x74/0x120

Re: possible lock issue on Oprofile

On 03.05.12 08:12:26, Maynard Johnson wrote:
> On 04/27/2012 03:15 PM, Breno Leitao wrote:
> > Hi,
> > 
> > I was just running oprofile with lock dependency enabled and I get the
> > following message, on a Power 730 with RHEL6.2.
> 
> Robert, does any of this look familiar to you?

See this stable fix:

 http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=commit;h=41f7082e5996807f0f535a251f235f64ae3d00e1

Should probably the same but didn't look into the rhel sources.

-Robert

> 
> -Maynard
> > 
> > =======================================================
> > [ INFO: possible circular locking dependency detected ]
> > 2.6.32-257.el6.ppc64.debug-breno #2
> > -------------------------------------------------------
> > oprofiled/21117 is trying to acquire lock:
> >  (buffer_mutex){+.+...}, at: [<d00000000f531678>] .sync_buffer+0x68/0x620
> > [oprofile]
> > 
> > but task is already holding lock:
> >  ((task_exit_notifier).rwsem){++++..}, at: [<c0000000000c88e4>]

[PATCH] Make new --separate-thread option for operf

[PATCH] Make new --separate-thread option for operf

This patch reverses the earlier decision to do "separate=thread" type
of functionality by default.  So now there is a command line option
to operf called "--separate-thread".  I decided to make this an option
for two reasons: 1) operf run in system-wide mode required the user to
either pass a tgid spec or to use "--merge=tgid" or the resulting report
was unreadable;  2) typically, the Java JIT compiler will spawn threads
to execute JITed code; so when using operf to profile a single Java app,
the resulting report is usually unreadable without using a tid spec or
"--merge=tid".

Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
---
 doc/operf.1.in                    |   32 ++++++++++++++++++++++----------
 libperf_events/operf_mangling.cpp |    8 +++++---
 libperf_events/operf_utils.h      |    1 +
 pe_profiling/operf.cpp            |   10 +++-------
 4 files changed, 31 insertions(+), 20 deletions(-)

diff --git a/doc/operf.1.in b/doc/operf.1.in
index c279323..00b6b2c 100644
--- a/doc/operf.1.in
+++ b/doc/operf.1.in
 <at>  <at>  -12,10 +12,9  <at>  <at>  operf \- Performance profiler tool for Linux
 [ --system-wide | --pid <pid> | [ command [ args ] ] ]

 .SH DESCRIPTION
-Operf is a Linux tool that can be used in place of opcontrol for profiling. Operf
-uses Linux Performance Events Subsystem, and hence, does not need the opcontrol daemon to be running

[PATCH] Fix regression to operf system-wide profiling caused by previous patch

[PATCH] Fix regression to operf system-wide profiling caused by previous patch

Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
---
 libperf_events/operf_process_info.h |   39 ++++++++++++++++++-----------------
 libperf_events/operf_utils.cpp      |    2 +-
 2 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/libperf_events/operf_process_info.h b/libperf_events/operf_process_info.h
index 1d9a791..ab4ff94 100644
--- a/libperf_events/operf_process_info.h
+++ b/libperf_events/operf_process_info.h
 <at>  <at>  -51,21 +51,13  <at>  <at>  struct operf_mmap {
 class operf_process_info {
 public:
 	operf_process_info(pid_t tgid, const char * appname, bool app_arg_is_fullname, bool is_valid);
-	bool is_valid(void) { return (valid && appname_valid()); }
+	bool is_valid(void) { return (valid); }
 	void process_new_mapping(struct operf_mmap * mapping);
 	void process_deferred_mappings(std::string app_shortname);
 	std::string get_app_name(void) { return _appname; }
 	void add_deferred_mapping(struct operf_mmap * mapping)
 	{ deferred_mmappings[mapping->start_addr] = mapping; }
 	const struct operf_mmap * find_mapping_for_sample(u64 sample_addr);
-private:
-	typedef enum {
-		NOT_FULLNAME,
-		MAYBE_FULLNAME,
-		YES_FULLNAME
-	} op_fullname_t;

Re: oprofile and ARM A9 hardware counter

Hi Will,

On 04/26/2012 01:07 PM, Will Deacon wrote:
> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>
>>> Part of the problem is that the clockdomain data for the emu_sys 
>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>> be enough to get it to work.
>>
>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>> use perf:
>>
>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>
>> which is new with your patch.
> 
> Sorry to nag, but does anybody have a clue where to go from here? I can
> start digging in the OMAP PM code, but it's all new territory for me.

I did a little playing around with this today and I think that I have figured out why this was not working (see
below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 

Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.

Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the
transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot
is running it is in the transitioning state. So even before the kernel starts. 

Cheers

Re: oprofile and ARM A9 hardware counter

Jon Hunter <jon-hunter <at> ti.com> writes:

> Hi Kevin,
>
> On 05/07/2012 12:15 PM, Kevin Hilman wrote:
>> Jon Hunter <jon-hunter <at> ti.com> writes:
>> 
>>> Hi Will,
>>>
>>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>>
>>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>>> be enough to get it to work.
>>>>>
>>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>>> use perf:
>>>>>
>>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>>
>>>>> which is new with your patch.
>>>>
>>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>>> start digging in the OMAP PM code, but it's all new territory for me.
>>>
>>> I did a little playing around with this today and I think that I have figured out why this was not working
(see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>>

Re: oprofile and ARM A9 hardware counter

On Tue, May 1, 2012 at 6:25 AM, Kevin Hilman <khilman <at> ti.com> wrote:

> Unfortunately, digging in the code isn't going to help much.
>
> We've been trying to get our heads around some undocumented reset
> behavior for the various debug IPs in OMAP.
>
> After a little digging and clarification from HW designers, it appears
> that if we allow the EMU clockdomain to idle, a full reset of the debug
> IPs is done.  That means there are two solutions to this problem:
>
> 1) don't ever alow EMU clockdomain to idle.
> 2) modify CTI driver to re-init for every use.
>
> Obviously (1) is the easiet, and hacks for that have already been
> posted, but that has pretty significant impacts on power savings.  (2)
> is the right solution to merge upstream, but needs writing.
>
> For (2), using runtime PM methods in the driver would be the simplest
> here since the ->runtime_resume method will be called every time the
> device is about to be used.

The previous patch has supported runtime pm on omap4 pmu[1], but still
didn't fix the problem. Could you comment on the patch and point out
the proper way to support pmu runtime for fixing the problem?

[1], http://marc.info/?l=linux-arm-kernel&m=131946777028358&w=2

Thanks,
--

Re: oprofile and ARM A9 hardware counter

Jon Hunter <jon-hunter <at> ti.com> writes:

> Hi Will,
>
> On 04/26/2012 01:07 PM, Will Deacon wrote:
>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>
>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>> be enough to get it to work.
>>>
>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>> use perf:
>>>
>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>
>>> which is new with your patch.
>> 
>> Sorry to nag, but does anybody have a clue where to go from here? I can
>> start digging in the OMAP PM code, but it's all new territory for me.
>
> I did a little playing around with this today and I think that I have figured out why this was not working (see
below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>
> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the mailing list.
>
> Also, the above error about the emu_pwrdm is odd too. I noticed that the emu_pwrdm is always in the
transitioning state. And when I say always, I mean that even if I check the power domain state while u-boot
is running it is in the transitioning state. So even before the kernel starts. 

Re: oprofile and ARM A9 hardware counter

Hi Kevin,

On 05/07/2012 12:15 PM, Kevin Hilman wrote:
> Jon Hunter <jon-hunter <at> ti.com> writes:
> 
>> Hi Will,
>>
>> On 04/26/2012 01:07 PM, Will Deacon wrote:
>>> On Wed, Apr 04, 2012 at 12:15:24PM +0100, Will Deacon wrote:
>>>> On Wed, Apr 04, 2012 at 12:29:49AM +0100, Paul Walmsley wrote:
>>>>>
>>>>> Part of the problem is that the clockdomain data for the emu_sys 
>>>>> clockdomain is wrong.  Here's something to try to fix it.  It might just 
>>>>> be enough to get it to work.
>>>>
>>>> Hmm, doesn't seem to work but I do see the following in dmesg when I try to
>>>> use perf:
>>>>
>>>>  powerdomain: waited too long for powerdomain emu_pwrdm to complete transition
>>>>
>>>> which is new with your patch.
>>>
>>> Sorry to nag, but does anybody have a clue where to go from here? I can
>>> start digging in the OMAP PM code, but it's all new territory for me.
>>
>> I did a little playing around with this today and I think that I have figured out why this was not working
(see below). Please can you try the following patch? I tried this on top of your series for perf/omap4. 
>>
>> Paul, FYI. If this works for Will then I can re-base on top of the latest linux-omap and submit to the
mailing list.

Need Help

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
oprofile-list mailing list
oprofile-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list