From: Carl Love <cel@us.ibm.com> To: Milton Miller <miltonm@bga.com> Cc: cbe-oss-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>, LKML <linux-kernel@vger.kernel.org>, linuxppc-dev@ozlabs.org, oprofile-list@lists.sourceforge.net Subject: Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch Date: Mon, 12 Feb 2007 08:38:35 -0800 [thread overview] Message-ID: <1171298315.5204.235.camel@dyn9047021078.beaverton.ibm.com> (raw) In-Reply-To: <fdeac69371a6b75fbf0ebffd30228106@bga.com> On Sun, 2007-02-11 at 16:46 -0600, Milton Miller wrote: [cut] > > As far as I understand, you are providing access to a completely new > hardware that is related to the PMU hardware by the fact that it > collects a program counter. It doesn't use the PMU counters nor the > PMU event selection. > > In fact, why can the existing op_model_cell profiling not run while > the SPU profiling runs? Is there a shared debug bus inside the > chip? Or just the data stream with your buffer_sync code? > There are two reasons you cannot do SPU profiling and profiling on non SPU events at the sametime. 1) the SPU PC values are routed on the debug bus. You cannot also route the signals for other non SPU events on the debug bus since they will conflict. Specifically, the signals would get logically OR'd on the bus. The exception is PPU cycles which does not use the debug bus. 2) the hardware that captures the SPU program counters has some shared components with the HW performance counters. To use the SPU program counter hardware, the performance counter hardware must be disabled. In summary, we cannot do SPU cycle profiling and non SPU event profiling at the same time due to limitations in the hardware. [cut] > milton >
WARNING: multiple messages have this Message-ID (diff)
From: Carl Love <cel@us.ibm.com> To: Milton Miller <miltonm@bga.com> Cc: linuxppc-dev@ozlabs.org, oprofile-list@lists.sourceforge.net, cbe-oss-dev@ozlabs.org, Arnd Bergmann <arnd@arndb.de>, LKML <linux-kernel@vger.kernel.org> Subject: Re: [Cbe-oss-dev] [RFC, PATCH] CELL Oprofile SPU profiling updated patch Date: Mon, 12 Feb 2007 08:38:35 -0800 [thread overview] Message-ID: <1171298315.5204.235.camel@dyn9047021078.beaverton.ibm.com> (raw) In-Reply-To: <fdeac69371a6b75fbf0ebffd30228106@bga.com> On Sun, 2007-02-11 at 16:46 -0600, Milton Miller wrote: [cut] > > As far as I understand, you are providing access to a completely new > hardware that is related to the PMU hardware by the fact that it > collects a program counter. It doesn't use the PMU counters nor the > PMU event selection. > > In fact, why can the existing op_model_cell profiling not run while > the SPU profiling runs? Is there a shared debug bus inside the > chip? Or just the data stream with your buffer_sync code? > There are two reasons you cannot do SPU profiling and profiling on non SPU events at the sametime. 1) the SPU PC values are routed on the debug bus. You cannot also route the signals for other non SPU events on the debug bus since they will conflict. Specifically, the signals would get logically OR'd on the bus. The exception is PPU cycles which does not use the debug bus. 2) the hardware that captures the SPU program counters has some shared components with the HW performance counters. To use the SPU program counter hardware, the performance counter hardware must be disabled. In summary, we cannot do SPU cycle profiling and non SPU event profiling at the same time due to limitations in the hardware. [cut] > milton >
next prev parent reply other threads:[~2007-02-12 16:39 UTC|newest] Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-02-06 0:28 [RFC,PATCH] CELL PPU Oprofile SPU profiling updated patch Carl Love 2007-02-06 0:46 ` Paul Mackerras 2007-02-06 0:46 ` Paul Mackerras 2007-02-06 0:49 ` [Cbe-oss-dev] [RFC, PATCH] " Benjamin Herrenschmidt 2007-02-06 0:49 ` Benjamin Herrenschmidt 2007-02-06 23:02 ` [Cbe-oss-dev] [RFC, PATCH] CELL " Carl Love 2007-02-06 23:02 ` Carl Love 2007-02-07 15:41 ` Maynard Johnson 2007-02-07 15:41 ` Maynard Johnson 2007-02-07 22:48 ` Michael Ellerman 2007-02-07 22:48 ` Michael Ellerman 2007-02-08 15:03 ` Maynard Johnson 2007-02-08 15:03 ` Maynard Johnson 2007-02-08 14:18 ` Milton Miller 2007-02-08 14:18 ` Milton Miller 2007-02-08 17:21 ` Arnd Bergmann 2007-02-08 17:21 ` Arnd Bergmann 2007-02-08 18:01 ` Adrian Reber 2007-02-08 18:01 ` Adrian Reber 2007-02-08 22:51 ` Carl Love 2007-02-08 22:51 ` Carl Love 2007-02-09 2:46 ` Milton Miller 2007-02-09 2:46 ` Milton Miller 2007-02-09 16:17 ` Carl Love 2007-02-09 16:17 ` Carl Love 2007-02-11 22:46 ` Milton Miller 2007-02-11 22:46 ` Milton Miller 2007-02-12 16:38 ` Carl Love [this message] 2007-02-12 16:38 ` Carl Love 2007-02-09 18:47 ` Milton Miller 2007-02-09 18:47 ` Milton Miller 2007-02-09 19:10 ` Arnd Bergmann 2007-02-09 19:10 ` Arnd Bergmann 2007-02-09 19:46 ` Milton Miller 2007-02-09 19:46 ` Milton Miller 2007-02-08 23:59 ` Maynard Johnson 2007-02-08 23:59 ` Maynard Johnson 2007-02-09 18:03 ` Milton Miller 2007-02-09 18:03 ` Milton Miller 2007-02-14 23:52 Carl Love 2007-02-15 14:37 ` Arnd Bergmann 2007-02-15 14:37 ` Arnd Bergmann 2007-02-15 16:15 ` Maynard Johnson 2007-02-15 16:15 ` Maynard Johnson 2007-02-15 18:13 ` Arnd Bergmann 2007-02-15 18:13 ` Arnd Bergmann 2007-02-15 20:21 ` Carl Love 2007-02-15 20:21 ` Carl Love 2007-02-15 21:03 ` Arnd Bergmann 2007-02-15 21:03 ` Arnd Bergmann 2007-02-15 21:50 ` Paul E. McKenney 2007-02-15 21:50 ` Paul E. McKenney 2007-02-16 0:33 ` Arnd Bergmann 2007-02-16 0:33 ` Arnd Bergmann 2007-02-16 0:32 ` Maynard Johnson 2007-02-16 0:32 ` Maynard Johnson 2007-02-16 17:14 ` Arnd Bergmann 2007-02-16 17:14 ` Arnd Bergmann 2007-02-16 21:43 ` Maynard Johnson 2007-02-16 21:43 ` Maynard Johnson 2007-02-18 23:18 ` Maynard Johnson 2007-02-18 23:18 ` Maynard Johnson 2007-02-22 0:02 Carl Love 2007-02-26 23:50 ` Arnd Bergmann 2007-02-26 23:50 ` Arnd Bergmann 2007-02-27 1:31 ` Michael Ellerman 2007-02-27 1:31 ` Michael Ellerman 2007-02-27 16:52 ` Maynard Johnson 2007-02-27 16:52 ` Maynard Johnson 2007-02-28 1:44 ` Arnd Bergmann 2007-02-28 1:44 ` Arnd Bergmann
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=1171298315.5204.235.camel@dyn9047021078.beaverton.ibm.com \ --to=cel@us.ibm.com \ --cc=arnd@arndb.de \ --cc=cbe-oss-dev@ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@ozlabs.org \ --cc=miltonm@bga.com \ --cc=oprofile-list@lists.sourceforge.net \ /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: linkBe 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.