stephane eranian wrote on 07/24/2009 05:31:16 PM:
[snip]
> But you run into the problem if the monitored process is using signals.
> For instance, if the program is using SIGALRM, then SIGIO may be
> delivered to the wrong thread. If your program does not use any signal
> then, you may be okay (
oops .. typo
Corey J Ashford/Beaverton/i...@ibmus wrote on 07/22/2009 11:29:22 AM:
> I know for a fact that it's possible to ptrace attach to threads
(tasks).
> We have a tool which relies on that + perfmon2 for per-thread
performance
> monitoring.
>
> If you are reall
es the line 136 prints the application thread id correctly. I also
> don't know what could be the problem. May be ptrace does not allow
> threadID as parameter. When will the version 2.6.30 be available?
>
> Thanks
> Tanima.
>
> From: Corey J Ashford
> To: Tanima Dey
>
d
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
Tanima Dey wrote on 07/20/2009 12:37:55 PM:
> Tanima Dey
> 07/20/2009 12:37 PM
>
> To
>
> Corey J Ashford/Beaverton/i...@ibmus
>
> cc
>
> Corey Ashford
Can you post the code where you are doing the fork/exec of the app, and
following ptrace call? Maybe we can spot the problem easier that way,
because I'm a little confused about the terminology "appThread". If
appThread is a pthread id, that would be the reason that ptrace is not
working... it
stephane eranian wrote on 07/15/2009 05:02:47 PM:
> On Wed, Jul 15, 2009 at 11:32 PM, Corey
> Ashford wrote:
> > (forgot to attach the patch, so here it is)
> >
> > Hi,
> >
> > I've made a stab at consolidating the event and group types for the
Power
> > chips (ppc970 through Power7).
> >
> > I'
Thanks, Stephane. I'm working on the changes to consolidate the types. I
should have the patch available tomorrow or Thursday.
- Corey
stephane eranian wrote on 07/14/2009 10:40:29 AM:
> On Tue, Jul 14, 2009 at 3:18 AM, stephane
> eranian wrote:
> > On Tue, Jul 14, 2009 at 2:58 AM, Corey
>
Can you back port the device driver to 2.6.29? It might be easier.
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
victor jimenez wrote on 07/08/2009 03:17:35 AM:
> Hello,
>
> because of a new ve
stephane eranian wrote on 06/19/2009 12:27:31 PM:
> On Fri, Jun 19, 2009 at 9:20 PM, stephane
> eranian wrote:
> > On Fri, Jun 19, 2009 at 9:03 PM, Corey J Ashford
wrote:
> >> Hi Stephane,
> >>
> >> For these sort of events which require multiple pmd
Hi Stephane,
For these sort of events which require multiple pmds, how does libpfm
describe to the caller the formula for combining the values from the pmds?
Or is it expected that the caller knows how?
- Corey
stephane eranian wrote on 06/19/2009 10:24:29 AM:
> Dan,
>
> Here is another l
stephane eranian wrote on 06/11/2009 09:17:45 AM:
> Corey,
> On Wed, Jun 10, 2009 at 8:04 PM, Corey J Ashford
wrote:
> > Yes, that could indeed be a problem but you are right that it is not
> > anticipated that
> > libpfm would be used in critical paths, but rather du
stephane eranian wrote on 06/10/2009 02:31:16 AM:
> Corey,
> On Wed, Jun 10, 2009 at 12:42 AM, Corey J Ashford
wrote:
> This looks great, Stephane.
>
> stephane eranian wrote on 06/09/2009 02:54:16
PM:
> >
> >
> >- the listing and event info API is stil
This looks great, Stephane.
stephane eranian wrote on 06/09/2009 02:54:16 PM:
> Hello,
>
> Here is an update on the current status of libpfm redesign, i.e.,
libpfm4.
> I have been playing around with some changes both visible and internal
> to take into account what we have discussed so far. I
ot initialize library. Most likely host PMU is not supported.
>
> Could you advice me, how do I load perfmon* modules?
> I also did the compilation of libpfm-3.2-060926 successfully. Does
> above error have relation with libpfm?
>
> Regards,
> Satoshi Isono
>
> -Original Mes
PAPI isn't really a tool in itself. It's an API (library) at a somewhat
higher abstraction level than libpfm. It provides a set abilities that
are not in libpfm (without some sort of tool). For example, it provides
an API for profiling, scaling counts for multiplexed events, etc., and it
pro
stephane eranian wrote on 06/04/2009 12:53:02 AM:
> Corey,
>
> On Wed, Jun 3, 2009 at 1:22 AM, Corey Ashford
> wrote:
> >
> > It seems like you could call the kernel-specific code for event
numbers
> > greater than the pmu-specific hardware event numbers. Basically, you
just
> > need a way to
Thanks for comments. Here are just a couple more:
stephane eranian wrote on 06/02/2009 07:44:11 AM:
> Corey,
>
> On Tue, Jun 2, 2009 at 12:53 AM, Corey J Ashford
wrote:
> > Yes, that's a tough problem because it's difficult to foresee every
> > possible attri
Thanks for the reply, Stephane,
stephane eranian wrote on 06/01/2009 09:34:39 AM:
> Corey,
>
> On Sat, May 30, 2009 at 12:01 AM, Corey Ashford
> wrote:
> >
> >
> > Philip Mucci wrote:
> >>
> >> Hi Stefane,
> >>
> >> Yeah, we talked about this on the phone. I personally think an
attribute
> >
victor jimenez wrote on 05/21/2009 02:12:18 AM:
> Hi Corey,
>
> calling to pfm_arch_clear_pmd_ovfl_cond() does not make any problem in
> the case of a context switch out, but it does when you only stop the
> counters and want to read them right after stopping them. In that
> case, because they h
victor jimenez wrote on 05/20/2009 09:24:43 AM:
> Hello,
>
> I did more tests and I think I found the reason why it is not working.
> I am attaching a log with the debug information. The log shows
> information between a call to sys_pfm_start() and sys_pfm_stop(), plus
> a following call to sys_
victor jimenez wrote on 05/19/2009 09:25:38 AM:
> Hello,
>
> I realized that the log may not look nicely, so I am attaching it as a
> text file.
>
> Victor
>
> On Tue, May 19, 2009 at 6:17 PM, victor jimenez
wrote:
> > Hello,
> >
> > I am using perfmon2 on IBM POWER5.
> > The version I am us
Hello Victor,
Thank you for taking the time post about this issue.
Power6's PMC 5 & 6 are a little problematic. There are several issues
with these counters:
- They count continuously (cannot be disabled), which means that in order
to use them on a per-thread basis, we have to virtualize them
Hello Lingchuan Meng,
Does your kernel have the perfmon2 patch set compiled into it? perfmon2
is not yet in the kernel.org kernel at this point nor in many distros, and
so you either need to patch your current kernel with the appropriate
perfmon2 patch set from here:
http://sourceforge.net/pr
ER_CPU_SYMBOL()
> is unknown.
>
> On Sat, Jan 17, 2009 at 12:41 AM, Corey J Ashford
wrote:
> > Hi Stephane,
> >
> > I tried the simplification you suggested below, but there is a
problem.
> > The pmu_ctx variable is not exported from the kernel, so the
>
Hi Stephane,
I tried the simplification you suggested below, but there is a problem.
The pmu_ctx variable is not exported from the kernel, so the
perfmon_power6.c module does not have visibility to it. As an experiment,
I tried adding
EXPORT_PER_CPU_SYMBOL(pmu_ctx);
in perfmon_init.c, but I
Hi Stephane,
Thanks for your review.
Well, I had seen two calls to pfm_power6_enable_counters in a row, so I
was concerned that the two calls to *enable_counters could overlap, and
both would see that the timer is not currently active, and both would call
hrtimer start on the same timer. A ra
Yes, that sounds like a better solution.
I will table this issue for now, since there are probably other problems
with those two examples as well.
It might not be a bad idea to put some
sort of warning in the code so that people are not surprised if the program
doesn't work. Something like:
"T
Hi Stephane,
"stephane eranian" wrote on 01/08/2009 12:25:56
PM:
> Corey,
>
>
> On Thu, Jan 8, 2009 at 8:58 PM, Corey Ashford
> wrote:
> > Hello,
> >
> > It appears that I have forgotten to post a patch for this bug. This
was a
> > problem I had seen when booting the latest 2.6.28-rc6 kern
atomic_read didn't work,
but did on x86_64.
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
cjash...@us.ibm.com
"stephane eranian" wrote on 01/07/2009 04:02:10
PM:
> On Thu, Jan 8, 2009 at 12:56 A
It's a 64-bit kernel App is 64-bits also, but I don't think that matters.
"stephane eranian" wrote on 01/07/2009 03:54:51
PM:
> Corey,
>
> On Thu, Jan 8, 2009 at 12:49 AM, Corey J Ashford
wrote:
> >
> > Yes, I didn't notice it before, b
>
> On Thu, Jan 8, 2009 at 12:27 AM, stephane eranian
> wrote:
> > Corey,
> >
> > Let me take a look at this. This is some nasty code in there.
> > But it is also old and we may be able simplify it. I don't think
> > it has to be that complicated. Pr
t; > printf("munmap failed\n");
> > }
> > }
> >
> > and it worked fine. So apparently there is a problem related to
> > munmap'ing a perfmon fd on Power. This will need more investigation,
> > obviously.
> >
> > - Corey
> >
> &g
t;
> The perfmon code that handles all of this is generic, so there must be a
> race condition somewhere which is only exposed on Power.
>
> On Wed, Jan 7, 2009 at 8:02 PM, Corey J Ashford
wrote:
> > Thanks for the reply, Stephane. I tried the test case you suggested:
> &g
Thanks, Stephane. I will make this change, test, and then re-submit the
patch soon.
- Corey
"stephane eranian" wrote on 01/06/2009 11:55:02
PM:
> Corey,
>
> I looked at the patch, and here is a recommendation:
>
> +static struct hrtimer pmc5_6_update[NR_CPUS];
>
> Use per-cpu variable ins
y
"stephane eranian" wrote on 01/06/2009 10:28:41
PM:
> Corey,
>
> On Wed, Jan 7, 2009 at 3:24 AM, Corey J Ashford
wrote:
> >
> > Hello,
> >
> > I'd appreciate it if someone on this mailing list could try out the
libpfm
> > example: task_sm
Hello,
I'd appreciate it if someone on this
mailing list could try out the libpfm example: task_smpl and see if it
runs correctly for you on any other architecture besides Power.
When I run it on my Power5-based machine
here, I get a system hang that occurs when the munmap call is made. Looking
Thanks for your reply, Stephane,
"stephane eranian" wrote on 12/18/2008 01:56:16
AM:
> Corey,
>
> I looked at the pfm_handle_work() code. Normally
> this functions gets called only if the TIF_PERFMON_WORK
> flag is set. On Power, it seems the logic is coded differently.
> You call systematical
Yes, except that time the problem ocurred with and without perfmon
enabled, while the stock kernel with no perfmon patch booted fine.
This one boots without perfmon enabled.
I've been looking at the diffs and so far I don't see anything yet, but
I'm still looking.
Regards,
- Corey
Corey Ashf
"stephane eranian" wrote on 12/12/2008 04:25:36
PM:
> Corey,
>
> On Sat, Dec 13, 2008 at 1:19 AM, Corey J Ashford
wrote:
> >>
> >> Question: is it possible to measure cycles twice on your machine?
> >
> > You mean in two different counters?
(forgot to cc perfmon2-devel on my reply)
"stephane eranian" wrote on 12/12/2008 04:03:51
PM:
> On Sat, Dec 13, 2008 at 12:57 AM, Corey J Ashford
wrote:
> > Thanks for the reply, Stephane.
> >
> > "stephane eranian" wrote on 12/11/2008
11:30:16
>
Thanks for the reply, Stephane.
"stephane eranian" wrote on 12/11/2008 11:30:16
PM:
> Corey,
>
> On Fri, Dec 12, 2008 at 4:08 AM, Corey J Ashford
wrote:
> > Thanks for the reply, Stephane,
> >
> > "stephane eranian" wrote on 12/11/2008
05
Thanks for the reply, Stephane,
"stephane eranian" wrote on 12/11/2008 05:35:21
PM:
> Corey,
>
> On Fri, Dec 12, 2008 at 1:48 AM, Corey Ashford
> wrote:
> > Hi Stephane,
> >
> > We are working through the example programs in the libpfm distribution
and
> > came across multiplex.c and multipl
Interesting. I don't see a description of how the counters can be linked
together in this new version.
I'm still wondering about the multiplexing capability (he calls it
scheduling)... how do you related a cycles count to each set for scaling
purposes? How do you know what is in each set?
R
At first glance:
this would push all of the libpfm-type of code into the kernel, where it's
harder to maintain.
it would be slower to read multiple counters, requiring one syscall per
counter.
how does it handle sampling and interrupt on overflow?
if scheduling of the counters is dynamic, I thin
d of the event was being used for the
edge and inv flags.
Is that the bug you were talking about?
- Corey
"stephane eranian" <[EMAIL PROTECTED]>
wrote on 12/03/2008 06:20:00 PM:
> Corey,
>
> On Thu, Dec 4, 2008 at 3:03 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
"stephane eranian" <[EMAIL PROTECTED]> wrote on 12/03/2008 05:02:03
PM:
> On Thu, Dec 4, 2008 at 1:37 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > Thanks for your reply.
> >
> > "stephane eranian" <[EMAIL PROTECTED]> wrote on 12/0
Thanks for your reply.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 12/03/2008 04:05:01
PM:
>
> One key principle of libpfm is that it tries to remain as
> independent of perfmon
> as possible. It does not use the same data structures nor flags. If
> knowing whether
> or not overflow is req
Philip Mucci <[EMAIL PROTECTED]> wrote on 11/28/2008 09:38:37 AM:
> > I will release support for core and uncore. But uncore will be
> > restricted to system-wide sessions only. It does not make sense
> > to support this for per-thread session, as there is no correlation
> > possible with a PID or
This is excellent news and progress, Stephane!
It wasn't clear to me from your more recent postings to LKML whether or
not you were planning to do those architecture posts yourself, or to rely
on the other contributors to do that.
Obviously, we have the advantage of being able to test arch (Po
t for perfmon3 and perfmon2.
>
>
> On Tue, Oct 28, 2008 at 2:34 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > Hi Stephane,
> >
> > I've been able to build and boot a perfmon3 kernel on a Power machine
with
> > no modifications so far. Good start!
&
Hi Stephane,
I've been able to build and boot a perfmon3 kernel on a Power machine with
no modifications so far. Good start!
However, using the latest libpfm from CVS, I'm unable to run any examples
which use the PMU. I get this errors similar to this:
./notify_self
sycall base 319
pfm_write
Thank you Robert. That did get me usable perfmon3 kernel source.
Regards,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
Robert Richter <[EMAIL PROTECTED]> wrote on 10/27/2008 05:30:59 PM:
> On 28.10.08 01:1
Hi Stephane,
Today I tried getting the perfmon3 branch from git, and was unsuccessful.
Here are the commands I ran:
% git clone
git://git.kernel.org/pub/scm/linux/kernel/git/eranian/linux-2.6
This succeeded, and then I tried:
% git-checkout perfmon3
error: pathspec 'perfmon3' did not match an
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/09/2008 02:46:21
PM:
> Hello,
>
> Following the discussion on LKML and on this list about the v3.0 API
> design, I have
> made some more changes to the existing v3.0 code base. The changes
reflects
> more or less the latest points discussed and
Thanks for the reply, Stephane. I have a follow-up comment:
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/05/2008 04:15:39
PM:
> Corey,
>
> On Mon, Oct 6, 2008 at 12:31 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > "stephane eranian"
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/05/2008 02:23:15
PM:
[snip]
> If I summarize our discussion. It seems we can define the API as
follows:
>
> int pfm_create_session(int fd, uint64_t flags, pfarg_sinfo_t *sif,
> [ char *smpl_name, void *smpl_arg, size_t arg_size]);
> int
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2008 06:56:58
AM:
> Hello,
>
>
> Here are two concerns about this new v3.0 and especially about the
> lightweight version
> which is what we will be starting with.
>
> The first issue is about the pfarg_pmr sructure which is defined as
fol
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/02/2008 08:20:14
AM:
[snip]
> int pfm_create_session(int flags, pfarg_session_info_t *sif,
>[char *smpl_name, void *smpl_arg, size_t
arg_size]);
>
> With:
>
> typedef struct {
>u64 sif_avail_pmcs[PFM_PMC_BV];
>u6
Thanks for the replay.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2008 01:07:29
PM:
> Corey,
>
> On Wed, Oct 1, 2008 at 8:24 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > "stephane eranian" <[EMAIL PROTECTED]> wrote on 10/01/2
This is good news, Stephane. Thank you. For power's need, I think we can
limit it to just a couple of functions.
I will post a proposal about what I'd like to add to libpfm, but it may not
be for awhile yet. We are looking ahead
to some degree.
Regards,
- Corey,
Corey Ashford
Software Engine
Vince Weaver <[EMAIL PROTECTED]> wrote on 08/15/2008 01:19:38 PM:
>
> On Fri, 15 Aug 2008, Corey J Ashford wrote:
> > Do the counters stop counting once they have overflowed? If so, your
patch
> > looks correct to me. Otherwise, the "== 0" will not work for ma
Do the counters stop counting once they have overflowed? If so, your patch
looks correct to me. Otherwise, the "== 0" will not work for many event
types (particularly a cycles counter) because it will have counted past
zero by the time you get into the interrupt handler. Is there some other
ove
02:54:23
PM:
> Corey,
>
> Good to hear, all is back to normal now.
>
> I think it would be beneficial for testing, if you could actually
> implement the detect/init decoupling so
> people could test Power 6 support on a Power 4 by using the
> LIBPFM_FORCE_PMU variable.
Thanks, Stephane. That fixed the issues I was having on POWER (tested on
POWER5 using PAPI 3.6.1 w/ configure --with-pfm-prefix=/usr/local)
Dan, you might consider pulling in these changes into PAPI's libpfm-3.y.
- Corey
"stephane eranian" <[EMAIL PROTECTED]> wrote on 08/07/2008 12:03:24
PM:
Hi Stephane,
Thanks for your reply.
The problem is that the (*p) data structure has not been initialized by the
time the check is made in "if ((*p)->pmu_type == forced_pmu)". Because the
structure has not been initialized, it contains all zeros, and so (*p)->
pmu_type IS equal to forced_pmu (wh
Just so you know, this is causing PAPI to not work with the latest kernel.
Should PAPI treat the 2.81 kernel as compatible with 2.8 libpfm?
Thanks,
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
"stephane erania
Hi Stephane,
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/23/2008 08:25:28
AM:
> Corey,
> On Wed, Jul 23, 2008 at 1:37 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> Thanks for your reply, Stephane. Some comments below.
>
> "stephane eranian&q
Thanks for your reply, Stephane. Some comments below.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/22/2008 04:11:18
PM:
> Corey,
>
> On Wed, Jul 23, 2008 at 1:03 AM, Corey Ashford <[EMAIL PROTECTED]>
wrote:
>
>> In this patch, I've also fixed the pfm_arch_restore_pmds to
>> correctly set
Hi Stephane,
Thanks for your detailed reply. One comment below. I will think more
about
this when I get to work.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/18/2008 08:22:44
AM:
> Corey,
[snip]
> Can you program the PMU interrupt to by edge sensitive and not level?
>
>
No, that is
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/17/2008 03:25:01
PM:
> On Fri, Jul 18, 2008 at 12:23 AM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > I think I understand what you are saying. POWER doesn't have a
stop_save
> > function, but it doe
r
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/17/2008 03:06:22
PM:
> Corey,
>
> On Thu, Jul 17, 2008 at 11:29 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > Hi Ste
Hi Stephane,
Sorry, the subject line was a bit long, but it is for POWER.
Well, the problem is that we do only check the used PMDs for overflows in
pfm_power6_get_ovfl_pmds (called from pfm_stop_active, called from
pfm_arch_stop), but when we switch to another set, those counters may or
may not
Hi Stephane,
On POWER, the interrupting PMDs start at 1. This was how I noticed it was
off because a loop was looking to see if register 0 has an interrupt
pending.
On Cell, the first interrupting PMD is register 0.
You could get rid of it, but since the fix is pretty simple, maybe we
should li
nt and update patch 5
> accordingly
> I noticed it was modifying the same file.
>
>
>
>
> On Tue, Jul 15, 2008 at 8:44 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > Hi Stephane,
> >
> > Yes, that code is in arch/powerpc/kernel/process.c
> >
> &
> - on counter overflow to record a sample
> - on unload for flush PMU state to software
>
> In all situations, interrupts are indeed disabled. So you should not need
> getcpu/putcpu.
>
>
> On Tue, Jul 15, 2008 at 6:46 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
>
[EMAIL PROTECTED]> wrote on 07/15/2008 11:36:50
AM:
> Corey,
>
> I assume what you are showing in Power specific. In that case, I agree
> in needs to be inside
> the critical section.
>
>
> On Tue, Jul 15, 2008 at 8:27 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrot
Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
"stephane eranian" <[EMAIL PROTECTED]>
07/15/2008 03:24 AM
Please respond to
[EMAIL PROTECTED]
To
Corey J Ashford/Beaverton/[EMAIL PROTECTED]
cc
perfmon2-devel@lists.sourceforge.net
Subject
Re: [PATCH 5/5] fixes for full p
Ok, thanks. I'll look into this tomorrow morning. It's probably a
POWER-specific thing.
- Corey
"stephane eranian" <[EMAIL PROTECTED]> wrote on 07/15/2008 12:42:11
AM:
> Corey,
>
>
> I have not seem this one yet.
>
>
> On Tue, Jul 15, 2008 at 3:53 AM, Corey Ashford <[EMAIL PROTECTED]>
ll from a specific point in the official tree
using:
> git pull ~/perfmon/official/linux-2.6 tag v2.6.26-rc9
>
> This way, I know the reference point and it is easier to share it with
> everybody.
>
> But I learned a new git command, thanks to Tony, to get the commi
Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
Corey J Ashford/Beaverton/[EMAIL PROTECTED] wrote:
> Thank you, Tony. I'm starting to understand this now. I think I've
> found the difference betwee
ce rc9, so I'm still confused, but
this is getting me closer.
Regards,
- Corey,
"Luck, Tony" <[EMAIL PROTECTED]> wrote on 07/09/2008 02:58:47 PM:
> "Luck, Tony" <[EMAIL PROTECTED]>
> 07/09/2008 02:58 PM
>
> To
>
> Corey J Ashford/
Hi Stephane,
Thanks for the advice. I'm not real familiar with git, so I'm probably
doing something wrong. I went to Linus's git tree on the git web
interface:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary
On the right side, is a link to "commit" which goes to:
h
I diffed the two console log files and found no interesting differences
except for the fact that eth0 comes up for
Linus' kernel and not for the perfmon kernel. Below is the diff of the two
logs.
$ diff eranian torvalds
38c38
< Starting Linux PPC64 #1 SMP Tue Jul 8 20:05:21 EDT 2008
---
> Startin
link with -lrt. If we go the latter route, at
> least the value should be correct...not what it is now.
>
> There must be a better answer...another sysfs file?
>
> Phil
>
> On Jul 7, 2008, at 8:29 PM, Corey J Ashford wrote:?
>
> Having dealt with this sort of "request som
[EMAIL PROTECTED] wrote on 07/07/2008 09:03:25
AM:
[snip]
> > - Another nit, the restriction that the multiplexing interface be
matched to
> > the clock-resolution. This is another big pain...as it requires codes
call
> > clock_getres() which is not in libc, thus they must link with librt or
else
>
On Tue, Jul 1, 2008 at 6:58 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > You might want to add a separate section that details the thinking
about
> > why you don't want to use a single, multiplexed syscall. If you add
this,
> > it could go after you've deta
Hi Stephane,
You might want to add a separate section that details the thinking about
why you don't want to use a single, multiplexed syscall. If you add this,
it could go after you've detailed the session breakdown, and before you've
described the current syscalls. I know this has been an ar
Hi Stephane,
Some responses below.
"stephane eranian" <[EMAIL PROTECTED]> wrote on 06/25/2008 07:21:06
AM:
> Corey,
>
>
> I looked at the two patches and I have the following comments:
>
> In the base patch:
>
> - arch/powerpc/perfmon/Kconfig
>you rely on your patch being stacked AFTER the
>
Hi Stephane,
I'm seeing some vestiges of pfm_restart in the x86 implementation. Is this
line supposed to be in there?
./include/asm-x86/unistd_64.h:#define __NR_pfm_restart
(__NR_pfm_create_context+7)
- Corey
Corey Ashford
Software Engineer
IBM Linux Technology Center, Linux Toolchain
Beaver
Hi Stephane,
Would you prefer to review the POWER base and POWER6 patches on this list
before I post them to the LKML mailing list?
By the way, I did get rid of the use of virtual registers in the POWER6
code. I think it's a positive change because it makes the code easier to
follow now.
- Co
Hi Stephane,
Working on the POWER6 port to the minimal perfmon2, I ran across a problem
that there is a gap in the syscall numbering, and on POWER arch this is
causing a problem because the check scripts expect that the numbering is
monotonic (no gaps).
The two solutions that come to mind are t
Toolchain
Beaverton, OR
503-578-3507
[EMAIL PROTECTED]
"stephane eranian" <[EMAIL PROTECTED]> wrote on 06/18/2008 02:47:13
PM:
> Corey,
>
> At which quilt level (quilt top) are you compiling this?
>
>
> On Wed, Jun 18, 2008 at 11:14 PM, Corey J Ashford <[EMAIL P
Hi Stephane,
I've tried out this kernel patch and ran into a minor error. There's a
config option under Hardware Performance Monitoring support called "Enable
perfmon statistics reporting via debugfs"
If I turn this on, I get a link-time error, because of the following lines
in perfmon/perfmon_p
Hi Stephane,
Thanks for your post.
I have a couple of questions for you:
1) After this initial x86-only patch has been accepted, will the next step
be to get other architecture ports accepted, or will something else come
first? As you might have guessed, we are interested in the getting POWER
You can see them in the patch. I only removed the final sentence about
modifying the macros.
One of them is in __pfm_ctxswin_thread, and says:
/*
* we need to lock context because it could be accessed
* from another CPU. Normally the schedule() functions
* has masked interrupts which should b
>
> On Thu, May 22, 2008 at 7:30 PM, Corey J Ashford <[EMAIL PROTECTED]>
wrote:
> > Thanks Stephane. I have no objection to removing those macros, but held
off
> > posting a patch for that because I remembered that Phil Mucci (as
discussed)
> > wanted to keep them.
&g
Thanks Stephane. I have no objection to removing those macros, but held
off posting a patch for that because I remembered that Phil Mucci (as
discussed) wanted to keep them.
Regards,
- Corey
"stephane eranian" <[EMAIL PROTECTED]> wrote on 05/22/2008 02:05:59
AM:
> Corey,
>
> Patch applied.
>
y
> > those that do irqsave/restore. Why? Because it could allow the
> > implementation of NMI's on systems that don't support them in hardware.
> >
> > Phil
> >
> >
> > On May 13, 2008, at 2:41 AM, Corey J Ashford wrote:
> >
> >
> &
Hi Stephane,
I tried out changing the wrapper for the PMU interrupt from
STD_EXCEPTION_PSERIES to MASKABLE_EXCEPTION_PSERIES then ran the test which
usually crashed within a minute or two, and it ran for 20 minutes non-stop.
Then I tried removing POWER's defines for pfm_spin_lock_irqsave (and so
Hi Stephane,
Thanks for your response.
I was thinking of trying out a kernel without the change, but I have a
strong suspicion that we are in the interrupt handler because of the
dreaded "soft interrupt disabling" optimization in POWER.
I'm going to start looking at the schedule code, but I'm af
1 - 100 of 107 matches
Mail list logo
