Arnd Bergmann wrote:
On Sunday 04 February 2007 00:49, Maynard Johnson wrote:
I seem to recall looking at this option a while back, but didn't go that
route since struct spu_context is opaque to me. With such a teqnique, I
could then use a simple 16-element array of pointers to
Arnd Bergmann wrote:
On Saturday 03 February 2007 21:03, Maynard Johnson wrote:
I presume you mean 'object_id'.
Right, sorry for the confusion.
What you're asking for is a new
requirement, and one which I don't believe is achievable in the current
timeframe. Since this is
Arnd Bergmann wrote:
On Saturday 03 February 2007 21:03, Maynard Johnson wrote:
I presume you mean 'object_id'.
Right, sorry for the confusion.
What you're asking for is a new
requirement, and one which I don't believe is achievable in the current
timeframe. Since this is
Arnd Bergmann wrote:
On Sunday 04 February 2007 00:49, Maynard Johnson wrote:
I seem to recall looking at this option a while back, but didn't go that
route since struct spu_context is opaque to me. With such a teqnique, I
could then use a simple 16-element array of pointers to
On Sunday 04 February 2007 00:49, Maynard Johnson wrote:
> I seem to recall looking at this option a while back, but didn't go that
> route since struct spu_context is opaque to me. With such a teqnique, I
> could then use a simple 16-element array of pointers to cached_info
> objects,
On Saturday 03 February 2007 21:03, Maynard Johnson wrote:
> I presume you mean 'object_id'.
Right, sorry for the confusion.
> What you're asking for is a new
> requirement, and one which I don't believe is achievable in the current
> timeframe. Since this is spufs code that's dynamicaly
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
[snip]
+ *
+ * Ideally, we would like to be able to create the cached_info for
+ * an SPU task just one time -- when libspe first loads the
Arnd Bergmann wrote:
On Friday 02 February 2007 17:47, Maynard Johnson wrote:
We also want to be able to profile the context switch code itself, which
means that we also need one event buffer associated with the kernel to
collect events that for a zero context_id.
The hardware
Arnd Bergmann wrote:
On Friday 02 February 2007 17:47, Maynard Johnson wrote:
We also want to be able to profile the context switch code itself, which
means that we also need one event buffer associated with the kernel to
collect events that for a zero context_id.
The hardware
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson wrote:
Subject: Add support to OProfile for profiling Cell BE SPUs
[snip]
+ *
+ * Ideally, we would like to be able to create the cached_info for
+ * an SPU task just one time -- when libspe first loads the
On Saturday 03 February 2007 21:03, Maynard Johnson wrote:
I presume you mean 'object_id'.
Right, sorry for the confusion.
What you're asking for is a new
requirement, and one which I don't believe is achievable in the current
timeframe. Since this is spufs code that's dynamicaly loaded
On Sunday 04 February 2007 00:49, Maynard Johnson wrote:
I seem to recall looking at this option a while back, but didn't go that
route since struct spu_context is opaque to me. With such a teqnique, I
could then use a simple 16-element array of pointers to cached_info
objects, creating
On Friday 02 February 2007 17:47, Maynard Johnson wrote:
>
> > We also want to be able to profile the context switch code itself, which
> > means that we also need one event buffer associated with the kernel to
> > collect events that for a zero context_id.
> The hardware design precludes tracing
Arnd Bergmann wrote:
On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
Arnd Bergmann wrote:
+ kt = ktime_set(0, profiling_interval);
+ if (!spu_prof_running)
+ goto STOP;
+ hrtimer_forward(timer, timer->base->get_time(), kt);
+ return
Arnd Bergmann wrote:
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
Why do you store them per spu in the first place? The physical spu
doesn't have any relevance to this at all, the only data that is
per spu is the sample data collected on a profiling interrupt,
which you can then
Arnd Bergmann wrote:
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
Why do you store them per spu in the first place? The physical spu
doesn't have any relevance to this at all, the only data that is
per spu is the sample data collected on a profiling interrupt,
which you can then
Arnd Bergmann wrote:
On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
Arnd Bergmann wrote:
+ kt = ktime_set(0, profiling_interval);
+ if (!spu_prof_running)
+ goto STOP;
+ hrtimer_forward(timer, timer-base-get_time(), kt);
+ return
On Friday 02 February 2007 17:47, Maynard Johnson wrote:
We also want to be able to profile the context switch code itself, which
means that we also need one event buffer associated with the kernel to
collect events that for a zero context_id.
The hardware design precludes tracing both
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
> >>Why do you store them per spu in the first place? The physical spu
> >>doesn't have any relevance to this at all, the only data that is
> >>per spu is the sample data collected on a profiling interrupt,
> >>which you can then copy in
On Wednesday 31 January 2007 00:31, Carl Love wrote:
> Unfortunately, the only way we know how to
> figure out what the LFSR value that corresponds to the number in the
> sequence that is N before the last value (0xFF) is to calculate the
> previous value N times. It is like trying to ask
On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
> Arnd Bergmann wrote:
> >>+ kt = ktime_set(0, profiling_interval);
> >>+ if (!spu_prof_running)
> >>+ goto STOP;
> >>+ hrtimer_forward(timer, timer->base->get_time(), kt);
> >>+ return HRTIMER_RESTART;
On Tue, 30 Jan 2007 15:31:09 -0800
Carl Love <[EMAIL PROTECTED]> wrote:
> An LFSR sequence is similar to a pseudo random number sequence. For a 24
> bit LFSR sequence each number between 0 and 2^24 will occur once in the
> sequence but not in a normal counting order. The hardware uses the LFSR
>
Benjamin Herrenschmidt wrote:
I've given this some more thought, and I'm coming to the conclusion that
a pure array-based implementation for holding cached_info (getting rid
of the lists) would work well for the vast majority of cases in which
OProfile will be used. Yes, it is true that the
> I've given this some more thought, and I'm coming to the conclusion that
> a pure array-based implementation for holding cached_info (getting rid
> of the lists) would work well for the vast majority of cases in which
> OProfile will be used. Yes, it is true that the mapping of an SPU
>
On Tue, 2007-01-30 at 15:41 -0600, Maynard Johnson wrote:
[snip
> [snip]
> >>+ // process the collected SPU PC for each node
> >>+ for_each_online_cpu(cpu) {
> >>+ if (cbe_get_hw_thread_id(cpu))
> >>+ continue;
> >>+
> >>+ node =
Christoph Hellwig wrote:
On Tue, Jan 30, 2007 at 06:53:50PM +1100, Benjamin Herrenschmidt wrote:
+/* Defines used for sync_start */
+#define SKIP_GENERIC_SYNC 0
+#define SYNC_START_ERROR -1
+#define DO_GENERIC_SYNC 1
+
+typedef struct vma_map
+{
+ struct vma_map *next;
+ unsigned
Maynard Johnson wrote:
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson 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
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson 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.
On Tue, Jan 30, 2007 at 06:53:50PM +1100, Benjamin Herrenschmidt wrote:
>
> > > +/* Defines used for sync_start */
> > > +#define SKIP_GENERIC_SYNC 0
> > > +#define SYNC_START_ERROR -1
> > > +#define DO_GENERIC_SYNC 1
> > > +
> > > +typedef struct vma_map
> > > +{
> > > + struct vma_map
On Tue, Jan 30, 2007 at 06:53:50PM +1100, Benjamin Herrenschmidt wrote:
+/* Defines used for sync_start */
+#define SKIP_GENERIC_SYNC 0
+#define SYNC_START_ERROR -1
+#define DO_GENERIC_SYNC 1
+
+typedef struct vma_map
+{
+ struct vma_map *next;
+ unsigned
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson 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.
Maynard Johnson wrote:
Arnd Bergmann wrote:
On Monday 29 January 2007 20:48, Maynard Johnson 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
Christoph Hellwig wrote:
On Tue, Jan 30, 2007 at 06:53:50PM +1100, Benjamin Herrenschmidt wrote:
+/* Defines used for sync_start */
+#define SKIP_GENERIC_SYNC 0
+#define SYNC_START_ERROR -1
+#define DO_GENERIC_SYNC 1
+
+typedef struct vma_map
+{
+ struct vma_map *next;
+ unsigned
On Tue, 2007-01-30 at 15:41 -0600, Maynard Johnson wrote:
[snip
[snip]
+ // process the collected SPU PC for each node
+ for_each_online_cpu(cpu) {
+ if (cbe_get_hw_thread_id(cpu))
+ continue;
+
+ node = cbe_cpu_to_node(cpu);
+
I've given this some more thought, and I'm coming to the conclusion that
a pure array-based implementation for holding cached_info (getting rid
of the lists) would work well for the vast majority of cases in which
OProfile will be used. Yes, it is true that the mapping of an SPU
context
Benjamin Herrenschmidt wrote:
I've given this some more thought, and I'm coming to the conclusion that
a pure array-based implementation for holding cached_info (getting rid
of the lists) would work well for the vast majority of cases in which
OProfile will be used. Yes, it is true that the
On Tue, 30 Jan 2007 15:31:09 -0800
Carl Love [EMAIL PROTECTED] wrote:
An LFSR sequence is similar to a pseudo random number sequence. For a 24
bit LFSR sequence each number between 0 and 2^24 will occur once in the
sequence but not in a normal counting order. The hardware uses the LFSR
On Tuesday 30 January 2007 22:41, Maynard Johnson wrote:
Arnd Bergmann wrote:
+ kt = ktime_set(0, profiling_interval);
+ if (!spu_prof_running)
+ goto STOP;
+ hrtimer_forward(timer, timer-base-get_time(), kt);
+ return HRTIMER_RESTART;
is
On Wednesday 31 January 2007 00:31, Carl Love wrote:
Unfortunately, the only way we know how to
figure out what the LFSR value that corresponds to the number in the
sequence that is N before the last value (0xFF) is to calculate the
previous value N times. It is like trying to ask what is
On Tuesday 30 January 2007 23:54, Maynard Johnson wrote:
Why do you store them per spu in the first place? The physical spu
doesn't have any relevance to this at all, the only data that is
per spu is the sample data collected on a profiling interrupt,
which you can then copy in the
> > +/* Defines used for sync_start */
> > +#define SKIP_GENERIC_SYNC 0
> > +#define SYNC_START_ERROR -1
> > +#define DO_GENERIC_SYNC 1
> > +
> > +typedef struct vma_map
> > +{
> > + struct vma_map *next;
> > + unsigned int vma;
> > + unsigned int size;
> > + unsigned int
+/* Defines used for sync_start */
+#define SKIP_GENERIC_SYNC 0
+#define SYNC_START_ERROR -1
+#define DO_GENERIC_SYNC 1
+
+typedef struct vma_map
+{
+ struct vma_map *next;
+ unsigned int vma;
+ unsigned int size;
+ unsigned int offset;
+
42 matches
Mail list logo
