From: Maynard Johnson <maynardj@us.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linuxppc-dev@ozlabs.org, cbe-oss-dev@ozlabs.org,
oprofile-list@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update
Date: Sat, 03 Feb 2007 17:49:00 -0600 [thread overview]
Message-ID: <45C51F6C.7080300@us.ibm.com> (raw)
In-Reply-To: <200701300839.05144.arnd@arndb.de>
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 SPU
>>+ * binary file. We would store the cached_info in a list. Then, as
>>+ * SPU tasks are switched out and new ones switched in, the cached_info
>>+ * for inactive tasks would be kept, and the active one would be placed
>>+ * at the head of the list. But this technique may not with
>>+ * current spufs functionality since the spu used in bind_context may
>>+ * be a different spu than was used in a previous bind_context for a
>>+ * reactivated SPU task. Additionally, a reactivated SPU task may be
>>+ * assigned to run on a different physical SPE. We will investigate
>>+ * further if this can be done.
>>+ *
>>+ */
>>
>>
>
>You should stuff a pointer to cached_info into struct spu_context,
>e.g. 'void *profile_private'.
>
>
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 them as needed when spu_context->profile_private is
NULL. I suppose the better option for now is to add a
get_profile_private() function to SPUFs, rather than requiring
spu_context to be visible. Don't know why I didn't think to do that
before. Ah, well, live and learn.
-Maynard
>
>
>>+struct cached_info {
>>+ vma_map_t * map;
>>+ struct spu * the_spu;
>>+ struct kref cache_ref;
>>+ struct list_head list;
>>+};
>>
>>
>
>And replace the 'the_spu' member with a back pointer to the
>spu_context if you need it.
>
>
>
> Arnd <><
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Maynard Johnson <maynardj@us.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: cbe-oss-dev@ozlabs.org, linux-kernel@vger.kernel.org,
linuxppc-dev@ozlabs.org, oprofile-list@lists.sourceforge.net
Subject: Re: [Cbe-oss-dev] [RFC, PATCH 4/4] Add support to OProfile for profiling Cell BE SPUs -- update
Date: Sat, 03 Feb 2007 17:49:00 -0600 [thread overview]
Message-ID: <45C51F6C.7080300@us.ibm.com> (raw)
In-Reply-To: <200701300839.05144.arnd@arndb.de>
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 SPU
>>+ * binary file. We would store the cached_info in a list. Then, as
>>+ * SPU tasks are switched out and new ones switched in, the cached_info
>>+ * for inactive tasks would be kept, and the active one would be placed
>>+ * at the head of the list. But this technique may not with
>>+ * current spufs functionality since the spu used in bind_context may
>>+ * be a different spu than was used in a previous bind_context for a
>>+ * reactivated SPU task. Additionally, a reactivated SPU task may be
>>+ * assigned to run on a different physical SPE. We will investigate
>>+ * further if this can be done.
>>+ *
>>+ */
>>
>>
>
>You should stuff a pointer to cached_info into struct spu_context,
>e.g. 'void *profile_private'.
>
>
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 them as needed when spu_context->profile_private is
NULL. I suppose the better option for now is to add a
get_profile_private() function to SPUFs, rather than requiring
spu_context to be visible. Don't know why I didn't think to do that
before. Ah, well, live and learn.
-Maynard
>
>
>>+struct cached_info {
>>+ vma_map_t * map;
>>+ struct spu * the_spu;
>>+ struct kref cache_ref;
>>+ struct list_head list;
>>+};
>>
>>
>
>And replace the 'the_spu' member with a back pointer to the
>spu_context if you need it.
>
>
>
> Arnd <><
>
>
next prev parent reply other threads:[~2007-02-03 23:49 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 19:45 [RFC, PATCH 0/4] Add support to OProfile for profiling Cell BE SPUs -- update Maynard Johnson
2007-01-29 19:46 ` [RFC, PATCH 1/4] " Maynard Johnson
2007-01-30 4:07 ` [Cbe-oss-dev] " Arnd Bergmann
2007-01-30 4:07 ` Arnd Bergmann
2007-01-30 10:39 ` Christoph Hellwig
2007-01-30 10:39 ` Christoph Hellwig
2007-01-30 22:49 ` Carl Love
2007-01-30 22:49 ` Carl Love
2007-01-30 22:57 ` Benjamin Herrenschmidt
2007-01-30 22:57 ` Benjamin Herrenschmidt
2007-01-31 8:47 ` Christoph Hellwig
2007-01-31 8:47 ` Christoph Hellwig
2007-01-30 22:59 ` Benjamin Herrenschmidt
2007-01-30 22:59 ` Benjamin Herrenschmidt
2007-01-29 19:47 ` [RFC, PATCH 2/4] " Maynard Johnson
2007-01-30 4:08 ` [Cbe-oss-dev] " Arnd Bergmann
2007-01-30 4:08 ` Arnd Bergmann
2007-01-30 23:51 ` Carl Love
2007-01-30 23:51 ` Carl Love
2007-01-29 19:48 ` [RFC, PATCH 3/4] " Maynard Johnson
2007-01-30 4:24 ` [Cbe-oss-dev] " Arnd Bergmann
2007-01-30 4:24 ` Arnd Bergmann
2007-01-30 15:31 ` Maynard Johnson
2007-01-30 15:31 ` Maynard Johnson
2007-01-31 0:35 ` Arnd Bergmann
2007-01-31 0:35 ` Arnd Bergmann
2007-01-29 19:48 ` [RFC, PATCH 4/4] " Maynard Johnson
2007-01-30 7:39 ` [Cbe-oss-dev] " Arnd Bergmann
2007-01-30 7:53 ` Benjamin Herrenschmidt
2007-01-30 7:53 ` Benjamin Herrenschmidt
2007-01-30 10:41 ` Christoph Hellwig
2007-01-30 10:41 ` Christoph Hellwig
2007-01-30 23:09 ` Maynard Johnson
2007-01-30 23:09 ` Maynard Johnson
2007-01-30 21:41 ` Maynard Johnson
2007-01-30 21:41 ` Maynard Johnson
2007-01-30 22:54 ` Maynard Johnson
2007-01-30 22:54 ` Maynard Johnson
2007-01-30 23:34 ` Benjamin Herrenschmidt
2007-01-30 23:34 ` Benjamin Herrenschmidt
2007-01-31 0:29 ` Maynard Johnson
2007-01-31 0:29 ` Maynard Johnson
2007-01-31 6:52 ` Arnd Bergmann
2007-01-31 6:52 ` Arnd Bergmann
2007-02-02 16:47 ` Maynard Johnson
2007-02-02 16:47 ` Maynard Johnson
2007-02-03 7:40 ` Arnd Bergmann
2007-02-03 7:40 ` Arnd Bergmann
2007-02-03 20:03 ` Maynard Johnson
2007-02-03 20:03 ` Maynard Johnson
2007-02-04 2:42 ` Arnd Bergmann
2007-02-04 2:42 ` Arnd Bergmann
2007-02-04 17:11 ` Maynard Johnson
2007-02-04 17:11 ` Maynard Johnson
2007-01-30 23:31 ` Carl Love
2007-01-30 23:31 ` Carl Love
2007-01-31 1:25 ` Christian Krafft
2007-01-31 1:25 ` Christian Krafft
2007-01-31 6:06 ` Arnd Bergmann
2007-01-31 6:06 ` Arnd Bergmann
2007-01-31 5:57 ` Arnd Bergmann
2007-01-31 5:57 ` Arnd Bergmann
2007-02-02 19:27 ` Maynard Johnson
2007-02-02 19:27 ` Maynard Johnson
2007-02-03 23:49 ` Maynard Johnson [this message]
2007-02-03 23:49 ` Maynard Johnson
2007-02-04 2:52 ` Arnd Bergmann
2007-02-04 2:52 ` Arnd Bergmann
2007-02-04 17:33 ` Maynard Johnson
2007-02-04 17:33 ` Maynard Johnson
2007-01-31 9:24 ` Milton Miller
2007-01-31 15:42 ` Arnd Bergmann
2007-02-01 18:56 ` Milton Miller
2007-02-02 0:54 ` Arnd Bergmann
2007-01-30 8:37 ` [RFC, PATCH 0/4] " Arnd Bergmann
2007-01-30 8:37 ` 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=45C51F6C.7080300@us.ibm.com \
--to=maynardj@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=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: link
Be 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.