[prev in list] [next in list] [prev in thread] [next in thread]
List: oprofile-list
Subject: Re: NMI driven oprofile for mips
From: "Lind, Paul" <plind () mips ! com>
Date: 2012-09-26 1:44:25
Message-ID: CC87A94A.70AC%plind () mips ! com
[Download RAW message or body]
Hi --
On the mips cores, the interrupt coming out of the core is called 'SI_PCInt=
'. This is typically fed back into the core though the interrupt controller=
. The actual interrupt number is the SoC vendor's choice. So the Linux supp=
ort for this must go in the SoC/board vendor's BSP. In this case, that woul=
d be Cavium.
A web search for Cavium Octeon Performance Counters, shows up this patch, t=
hat makes it look like they default it to IRQ 6. Looks like you want to stu=
dy the CvmCtl register in the CP0 regs.
http://patchwork.linux-mips.org/patch/1927/
paul
From: Ghitulete Razvan <razvan.ghitulete@gmail.com<mailto:razvan.ghitulete@=
gmail.com>>
Date: Tuesday, September 25, 2012 1:49 AM
To: Paul Lind <plind@mips.com<mailto:plind@mips.com>>
Cc: "oprofile-list@lists.sf.net<mailto:oprofile-list@lists.sf.net>" <oprofi=
le-list@lists.sf.net<mailto:oprofile-list@lists.sf.net>>
Subject: Re: NMI driven oprofile for mips
On Tue, Sep 25, 2012 at 8:10 AM, Lind, Paul <plind@mips.com<mailto:plind@mi=
ps.com>> wrote:
Sorry, but there currently is no support for NMI profiling on MIPS, as you =
have seen. I will give you a little background as to why this is.
On most cores, the performance counter event count interrupt output is wire=
d thru the external interrupt controller, and fed back to the core as an in=
terrupt. This connection is usually fixed in silicon, so you often would no=
t have the opportunity to rewire this to NMI. However, on many cores, the r=
outing thru the interrupt controller is flexible, and you can change the in=
terrupt priority. That would be true on the MIPS GIC interrupt controller, =
if you have that in your core. So you should be able to make this the highe=
st priority interrupt.
On Linux the intent of the interrupt code is to re-enable interrupts as qui=
ckly as possible, and to allow interrupt nesting. So hopefully your other d=
rivers cooperate, and oprofile can sample the other interrupt handlers, if =
that is where your interest lies. Of course, since this is a maskable inter=
rupt, you cannot get accurate profiling for code that does disable all inte=
rrupts.
If you have a core that you can re-route performance counter interrupt to N=
MI, it should be possible to write a handler, but it will be a little trick=
y. The NMI is passed thru a vector very similar to the reset vector, which =
means you start up in uncached code, probably in your boot rom. There is so=
me support in Yamon boot loader for passing these events back into Linux, b=
ut I am sure you will have to do a bit of very low level coding to get this=
working.
Hope this helps, and sorry if it was not the news you wanted to hear,
Hi Paul,
This was a long-shot and I was expecting such an answer, so thanks for t=
he prompt response. Though before I give up on this issue I was wondering w=
hat interrupt does the perfcount register actually generate because from th=
e datasheet (cavium octeon) I can't seem to find such info.
--
Sincerely,
Razvan Ghitulete
Universitatea Politehnica Bucuresti
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: \
after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, \
sans-serif; "> <div>Hi -- </div>
<div><br>
</div>
<div>On the mips cores, the interrupt coming out of the core is called 'SI_PCInt'. \
This is typically fed back into the core though the interrupt controller. The actual \
interrupt number is the SoC vendor's choice. So the Linux support for this must go in \
the SoC/board vendor's BSP. In this case, that would be Cavium.</div>
<div><br>
</div>
<div>A web search for Cavium Octeon Performance Counters, shows up this patch, that \
makes it look like they default it to IRQ 6. Looks like you want to study the CvmCtl \
register in the CP0 regs.</div> <div><br>
</div>
<div><a href="http://patchwork.linux-mips.org/patch/1927">http://patchwork.linux-mips.org/patch/1927</a>/</div>
<div><br>
</div>
<div>paul</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; \
BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; \
PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: \
medium none; PADDING-TOP: 3pt"> <span style="font-weight:bold">From: </span>Ghitulete \
Razvan <<a href="mailto:razvan.ghitulete@gmail.com">razvan.ghitulete@gmail.com</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, September 25, 2012 1:49 AM<br>
<span style="font-weight:bold">To: </span>Paul Lind <<a \
href="mailto:plind@mips.com">plind@mips.com</a>><br> <span \
style="font-weight:bold">Cc: </span>"<a \
href="mailto:oprofile-list@lists.sf.net">oprofile-list@lists.sf.net</a>" <<a \
href="mailto:oprofile-list@lists.sf.net">oprofile-list@lists.sf.net</a>><br> <span \
style="font-weight:bold">Subject: </span>Re: NMI driven oprofile for mips<br> </div>
<div><br>
</div>
<div>
<div><br>
<div class="gmail_quote">On Tue, Sep 25, 2012 at 8:10 AM, Lind, Paul <span dir="ltr">
<<a href="mailto:plind@mips.com" target="_blank">plind@mips.com</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <div \
style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word"> \
<div>Sorry, but there currently is no support for NMI profiling on MIPS, as you have \
seen. I will give you a little background as to why this is.</div> <div><br>
</div>
<div>On most cores, the performance counter event count interrupt output is wired \
thru the external interrupt controller, and fed back to the core as an interrupt. \
This connection is usually fixed in silicon, so you often would not have the \
opportunity to rewire this to NMI. However, on many cores, the routing thru the \
interrupt controller is flexible, and you can change the interrupt priority. That \
would be true on the MIPS GIC interrupt controller, if you have that in your core. So \
you should be able to make this the highest priority interrupt.</div>
<div><br>
</div>
<div>On Linux the intent of the interrupt code is to re-enable interrupts as quickly \
as possible, and to allow interrupt nesting. So hopefully your other drivers \
cooperate, and oprofile can sample the other interrupt handlers, if that is where \
your interest lies. Of course, since this is a maskable interrupt, you cannot get \
accurate profiling for code that does disable all interrupts.</div> <div><br>
</div>
<div>If you have a core that you can re-route performance counter interrupt to NMI, \
it should be possible to write a handler, but it will be a little tricky. The NMI is \
passed thru a vector very similar to the reset vector, which means you start up in \
uncached code, probably in your boot rom. There is some support in Yamon boot loader \
for passing these events back into Linux, but I am sure you will have to do a bit of \
very low level coding to get this working.</div> <div><br>
</div>
<div>Hope this helps, and sorry if it was not the news you wanted to hear,</div>
<div><br>
</div>
<div><br>
</div>
</div>
</blockquote>
<div>Hi Paul,</div>
<div> This was a long-shot and I was expecting such an answer, so thanks \
for the prompt response. Though before I give up on this issue I was wondering what \
interrupt does the perfcount register actually generate because from the datasheet \
(cavium octeon) I can't seem to find such info. </div>
<div> </div>
</div>
-- <br>
<div>Sincerely, </div>
Razvan Ghitulete<br>
Universitatea Politehnica Bucuresti<br>
</div>
</div>
</span>
</body>
</html>
[Attachment #4 (--===============1056916360515847899==)]
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic