On Tuesday 27 February 2007, Maynard Johnson wrote:
> I have applied the "cleanup" patch that Arnd sent, but had to fix up a
> few things:
> - Bug fix: Initialize retval in spu_task_sync.c, line 95, otherwise
> OProfile this function returns non-zero and OProfile fails.
> - Remove
I have applied the "cleanup" patch that Arnd sent, but had to fix up a
few things:
- Bug fix: Initialize retval in spu_task_sync.c, line 95, otherwise
OProfile this function returns non-zero and OProfile fails.
- Remove unused codes in include/linux/oprofile.h
- Compile warnings:
I have applied the cleanup patch that Arnd sent, but had to fix up a
few things:
- Bug fix: Initialize retval in spu_task_sync.c, line 95, otherwise
OProfile this function returns non-zero and OProfile fails.
- Remove unused codes in include/linux/oprofile.h
- Compile warnings:
On Tuesday 27 February 2007, Maynard Johnson wrote:
I have applied the cleanup patch that Arnd sent, but had to fix up a
few things:
- Bug fix: Initialize retval in spu_task_sync.c, line 95, otherwise
OProfile this function returns non-zero and OProfile fails.
- Remove unused codes
On Tue, 2007-02-27 at 00:50 +0100, Arnd Bergmann wrote:
> On Thursday 22 February 2007, Carl Love wrote:
> > This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
> > to add in the SPU profiling capabilities. In addition, a 'cell'
> > subdirectory
> > was added to
On Thursday 22 February 2007, Carl Love wrote:
> This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
> to add in the SPU profiling capabilities. In addition, a 'cell' subdirectory
> was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling
> code.
There was a
On Thursday 22 February 2007, Carl Love wrote:
This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
to add in the SPU profiling capabilities. In addition, a 'cell' subdirectory
was added to arch/powerpc/oprofile to hold Cell-specific SPU profiling
code.
There was a
On Tue, 2007-02-27 at 00:50 +0100, Arnd Bergmann wrote:
On Thursday 22 February 2007, Carl Love wrote:
This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
to add in the SPU profiling capabilities. In addition, a 'cell'
subdirectory
was added to arch/powerpc/oprofile to
Maynard Johnson wrote:
Arnd Bergmann wrote:
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
config OPROFILE_CELL
bool "OProfile for Cell Broadband Engine"
depends on OPROFILE && SPU_FS
default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m &&
OPROFILE
Maynard Johnson wrote:
Arnd Bergmann wrote:
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
config OPROFILE_CELL
bool OProfile for Cell Broadband Engine
depends on OPROFILE SPU_FS
default y if ((SPU_FS = y OPROFILE = y) || (SPU_FS = m
OPROFILE = m))
Arnd Bergmann wrote:
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
config OPROFILE_CELL
bool "OProfile for Cell Broadband Engine"
depends on OPROFILE && SPU_FS
default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m &&
OPROFILE = m))
help
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
> config OPROFILE_CELL
> bool "OProfile for Cell Broadband Engine"
> depends on OPROFILE && SPU_FS
> default y if ((SPU_FS = y && OPROFILE = y) || (SPU_FS = m &&
> OPROFILE = m))
> help
> Profiling
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
config OPROFILE_CELL
bool OProfile for Cell Broadband Engine
depends on OPROFILE SPU_FS
default y if ((SPU_FS = y OPROFILE = y) || (SPU_FS = m
OPROFILE = m))
help
Profiling of Cell BE SPUs
Arnd Bergmann wrote:
On Friday 16 February 2007 01:32, Maynard Johnson wrote:
config OPROFILE_CELL
bool OProfile for Cell Broadband Engine
depends on OPROFILE SPU_FS
default y if ((SPU_FS = y OPROFILE = y) || (SPU_FS = m
OPROFILE = m))
help
Profiling
Arnd Bergmann wrote:
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@
config
On Thursday 15 February 2007 22:50, Paul E. McKenney wrote:
> Is this 1.5ms with interrupts disabled? This time period is problematic
> from a realtime perspective if so -- need to be able to preempt.
No, interrupts should be enabled here. Still, 1.5ms is probably a little
too long without a
On Thu, Feb 15, 2007 at 12:21:58PM -0800, Carl Love wrote:
> On Thu, 2007-02-15 at 15:37 +0100, Arnd Bergmann wrote:
[ . . . ]
> > I agree with Milton that it would be far nicer even to calculate
> > the value from user space, but since you say that would
> > violate the oprofile interface
On Thursday 15 February 2007 21:21, Carl Love wrote:
> I have done some quick measurements. The above method limits the loop
> to at most 2^16 iterations. Based on running the algorithm in user
> space, it takes about 3ms of computation time to do the loop 2^16 times.
>
> At the vary least, we
On Thu, 2007-02-15 at 15:37 +0100, Arnd Bergmann wrote:
> On Thursday 15 February 2007 00:52, Carl Love wrote:
>
>
> > --- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
> > 16:43:14.0 -0600
> > +++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
> >
On Thursday 15 February 2007 17:15, Maynard Johnson wrote:
> >>+void spu_set_profile_private(struct spu_context * ctx, void * profile_info,
> >>+ struct kref * prof_info_kref,
> >>+ void (* prof_info_release) (struct kref * kref))
> >>+{
> >>+
Arnd Bergmann wrote:
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@
config
On Thursday 15 February 2007 00:52, Carl Love wrote:
> --- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
> 16:43:14.0 -0600
> +++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig2007-02-13
> 19:04:46.271028904 -0600
> @@ -7,7 +7,8 @@
>
> config OPROFILE
>
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig2007-02-13
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@
config OPROFILE
Arnd Bergmann wrote:
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@
config
On Thursday 15 February 2007 17:15, Maynard Johnson wrote:
+void spu_set_profile_private(struct spu_context * ctx, void * profile_info,
+ struct kref * prof_info_kref,
+ void (* prof_info_release) (struct kref * kref))
+{
+
On Thu, 2007-02-15 at 15:37 +0100, Arnd Bergmann wrote:
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
On Thursday 15 February 2007 21:21, Carl Love wrote:
I have done some quick measurements. The above method limits the loop
to at most 2^16 iterations. Based on running the algorithm in user
space, it takes about 3ms of computation time to do the loop 2^16 times.
At the vary least, we need
On Thu, Feb 15, 2007 at 12:21:58PM -0800, Carl Love wrote:
On Thu, 2007-02-15 at 15:37 +0100, Arnd Bergmann wrote:
[ . . . ]
I agree with Milton that it would be far nicer even to calculate
the value from user space, but since you say that would
violate the oprofile interface conventions,
On Thursday 15 February 2007 22:50, Paul E. McKenney wrote:
Is this 1.5ms with interrupts disabled? This time period is problematic
from a realtime perspective if so -- need to be able to preempt.
No, interrupts should be enabled here. Still, 1.5ms is probably a little
too long without a
Arnd Bergmann wrote:
On Thursday 15 February 2007 00:52, Carl Love wrote:
--- linux-2.6.20-rc1.orig/arch/powerpc/oprofile/Kconfig 2007-01-18
16:43:14.0 -0600
+++ linux-2.6.20-rc1/arch/powerpc/oprofile/Kconfig 2007-02-13
19:04:46.271028904 -0600
@@ -7,7 +7,8 @@
config
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
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.
On Feb 9, 2007, at 10:17 AM, Carl Love wrote:
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
On Feb 9, 2007, at 10:17 AM, Carl Love wrote:
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
On Feb 9, 2007, at 1:10 PM, Arnd Bergmann wrote:
On Friday 09 February 2007 19:47, Milton Miller wrote:
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
Doing the translation in two stages in user space, as you
suggest here, definitely makes sense to me. I think it
can be done a little
On Friday 09 February 2007 19:47, Milton Miller wrote:
> On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
>
> > Doing the translation in two stages in user space, as you
> > suggest here, definitely makes sense to me. I think it
> > can be done a little simpler though:
> >
> > Why would you
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
The current patch specifically identifies that only single
elf objects are handled. There is no code to handle dynamic
linked libraries or overlays. Nor is there any method to
On Feb 8, 2007, at 5:59 PM, Maynard Johnson wrote:
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
Thanks for the pleasant tone and dialog.
Milton Miller wrote:
On Feb 6, 2007, at 5:02
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
> On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
>
> > On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
> >> On Thursday 08 February 2007 15:18, Milton Miller wrote:
> >>
> >>> 1) sample rate setup
> >>>
> >>> In the current
On Thu, 2007-02-08 at 20:46 -0600, Milton Miller wrote:
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a
On Feb 8, 2007, at 5:59 PM, Maynard Johnson wrote:
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
Thanks for the pleasant tone and dialog.
Milton Miller wrote:
On Feb 6, 2007, at 5:02
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
The current patch specifically identifies that only single
elf objects are handled. There is no code to handle dynamic
linked libraries or overlays. Nor is there any method to
On Friday 09 February 2007 19:47, Milton Miller wrote:
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
Doing the translation in two stages in user space, as you
suggest here, definitely makes sense to me. I think it
can be done a little simpler though:
Why would you need the
On Feb 9, 2007, at 1:10 PM, Arnd Bergmann wrote:
On Friday 09 February 2007 19:47, Milton Miller wrote:
On Feb 8, 2007, at 11:21 AM, Arnd Bergmann wrote:
Doing the translation in two stages in user space, as you
suggest here, definitely makes sense to me. I think it
can be done a little
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
-Maynard
Milton Miller wrote:
On Feb 6, 2007, at 5:02 PM, Carl Love wrote:
This is the first update to the patch previously posted by
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
> On Thursday 08 February 2007 15:18, Milton Miller wrote:
>
> > 1) sample rate setup
> >
> > In the current patch, the user specifies a sample rate as a time
> > interval.
> > The kernel is (a) calling cpufreq to get the current
On Thu, Feb 08, 2007 at 06:21:56PM +0100, Arnd Bergmann wrote:
[...]
> Moving the sample rate computation to user space sounds like the right
> idea, but why not have a more drastic version of it:
>
> Right now, all products that support this feature run at the same clock
> rate (3.2 Ghz), with
On Thursday 08 February 2007 15:18, Milton Miller wrote:
> 1) sample rate setup
>
> In the current patch, the user specifies a sample rate as a time
> interval.
> The kernel is (a) calling cpufreq to get the current cpu frequency,
> (b)
> converting the rate to a cycle count, (c)
Michael,
Thanks very much for the advice. Both issues have been solved now, with
your help.
-Maynard
Michael Ellerman wrote:
On Wed, 2007-02-07 at 09:41 -0600, Maynard Johnson wrote:
Carl Love wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
From: Maynard
On Feb 6, 2007, at 5:02 PM, Carl Love wrote:
This is the first update to the patch previously posted by Maynard
Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL".
This repost fixes the line wrap issue that Ben mentioned. Also the
kref
handling for the cached info has been
On Feb 6, 2007, at 5:02 PM, Carl Love wrote:
This is the first update to the patch previously posted by Maynard
Johnson as PATCH 4/4. Add support to OProfile for profiling CELL.
This repost fixes the line wrap issue that Ben mentioned. Also the
kref
handling for the cached info has been
Michael,
Thanks very much for the advice. Both issues have been solved now, with
your help.
-Maynard
Michael Ellerman wrote:
On Wed, 2007-02-07 at 09:41 -0600, Maynard Johnson wrote:
Carl Love wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
From: Maynard
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling cpufreq to get the current cpu frequency,
(b)
converting the rate to a cycle count, (c)
On Thu, Feb 08, 2007 at 06:21:56PM +0100, Arnd Bergmann wrote:
[...]
Moving the sample rate computation to user space sounds like the right
idea, but why not have a more drastic version of it:
Right now, all products that support this feature run at the same clock
rate (3.2 Ghz), with
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling cpufreq to get the current cpu
Milton,
Thank you for your comments. Carl will reply to certain parts of your
posting where he's more knowledgeable than I. See my replies below.
-Maynard
Milton Miller wrote:
On Feb 6, 2007, at 5:02 PM, Carl Love wrote:
This is the first update to the patch previously posted by
On Feb 8, 2007, at 4:51 PM, Carl Love wrote:
On Thu, 2007-02-08 at 18:21 +0100, Arnd Bergmann wrote:
On Thursday 08 February 2007 15:18, Milton Miller wrote:
1) sample rate setup
In the current patch, the user specifies a sample rate as a time
interval.
The kernel is (a) calling
On Wed, 2007-02-07 at 09:41 -0600, Maynard Johnson wrote:
> Carl Love wrote:
>
> >
> >Subject: Add support to OProfile for profiling Cell BE SPUs
> >
> >From: Maynard Johnson <[EMAIL PROTECTED]>
> >
> >This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
> >to add in the SPU
Carl Love wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
From: Maynard Johnson <[EMAIL PROTECTED]>
This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
to add in the SPU profiling capabilities. In addition, a 'cell' subdirectory
was added to
Carl Love wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
From: Maynard Johnson [EMAIL PROTECTED]
This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
to add in the SPU profiling capabilities. In addition, a 'cell' subdirectory
was added to
On Wed, 2007-02-07 at 09:41 -0600, Maynard Johnson wrote:
Carl Love wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
From: Maynard Johnson [EMAIL PROTECTED]
This patch updates the existing arch/powerpc/oprofile/op_model_cell.c
to add in the SPU profiling
This is the first update to the patch previously posted by Maynard
Johnson as "PATCH 4/4. Add support to OProfile for profiling CELL".
This repost fixes the line wrap issue that Ben mentioned. Also the kref
handling for the cached info has been fixed and simplified.
There are still a few
This is the first update to the patch previously posted by Maynard
Johnson as PATCH 4/4. Add support to OProfile for profiling CELL.
This repost fixes the line wrap issue that Ben mentioned. Also the kref
handling for the cached info has been fixed and simplified.
There are still a few items
64 matches
Mail list logo
