From: Nathan Lynch <ntl@pobox.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Paul Mackerras <paulus@samba.org>,
linuxppc64-dev@ozlabs.org, Arnd Bergmann <arndb@de.ibm.com>,
linux-kernel@vger.kernel.org, Mark Nutter <mnutter@us.ibm.com>,
Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [PATCH 13/13] spufs: set irq affinity for running threads
Date: Wed, 4 Jan 2006 22:42:27 -0600 [thread overview]
Message-ID: <20060105044227.GD16729@localhost.localdomain> (raw)
In-Reply-To: <20060104194502.253418000@localhost>
Arnd Bergmann wrote:
> For far, all SPU triggered interrupts always end up on
> the first SMT thread, which is a bad solution.
>
> This patch implements setting the affinity to the
> CPU that was running last when entering execution on
> an SPU. This should result in a significant reduction
> in IPI calls and better cache locality for SPE thread
> specific data.
...
> --- linux-2.6.15-rc.orig/arch/powerpc/platforms/cell/spufs/sched.c
> +++ linux-2.6.15-rc/arch/powerpc/platforms/cell/spufs/sched.c
> @@ -357,6 +357,11 @@ int spu_activate(struct spu_context *ctx
> if (!spu)
> return (signal_pending(current)) ? -ERESTARTSYS : -EAGAIN;
> bind_context(spu, ctx);
> + /*
> + * We're likely to wait for interrupts on the same
> + * CPU that we are now on, so send them here.
> + */
> + spu_irq_setaffinity(spu, smp_processor_id());
With CONFIG_DEBUG_PREEMPT this will give a warning about using
smp_processor_id in pre-emptible context if I'm reading the code
correctly.
Maybe use raw_smp_processor_id, since setting the affinity to this cpu
isn't a hard requirement?
next prev parent reply other threads:[~2006-01-05 4:41 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-04 19:31 [PATCH 00/13] spufs fixes and cleanups Arnd Bergmann
2006-01-04 19:31 ` [PATCH 01/13] spufs: fix locking in spu_acquire_runnable Arnd Bergmann
2006-01-04 19:31 ` [PATCH 02/13] spufs: dont hold root->isem in spu_forget Arnd Bergmann
2006-01-04 19:31 ` [PATCH 03/13] spufs: check for proper file pointer in sys_spu_run Arnd Bergmann
2006-01-04 19:31 ` [PATCH 04/13] spufs: serialize sys_spu_run per spu Arnd Bergmann
2006-01-04 19:31 ` [PATCH 05/13] spufs fix spu_acquire_runnable error path Arnd Bergmann
2006-01-04 19:31 ` [PATCH 06/13] spufs: dont leak directories in failed spu_create Arnd Bergmann
2006-01-04 19:31 ` [PATCH 07/13] spufs: fix spufs_fill_dir error path Arnd Bergmann
2006-01-04 19:31 ` [PATCH 08/13] spufs: clean up use of bitops Arnd Bergmann
2006-01-04 19:31 ` [PATCH 09/13] spufs: move spu_run call to its own file Arnd Bergmann
2006-01-04 19:31 ` [PATCH 10/13] spufs: abstract priv1 register access Arnd Bergmann
2006-01-04 19:31 ` [PATCH 11/13] spufs: fix sparse warnings Arnd Bergmann
2006-01-04 19:31 ` [PATCH 12/13] spufs: fix allocation on 64k pages Arnd Bergmann
2006-01-04 19:31 ` [PATCH 13/13] spufs: set irq affinity for running threads Arnd Bergmann
2006-01-05 4:42 ` Nathan Lynch [this message]
2006-01-05 14:05 ` 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=20060105044227.GD16729@localhost.localdomain \
--to=ntl@pobox.com \
--cc=arnd@arndb.de \
--cc=arndb@de.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=mnutter@us.ibm.com \
--cc=paulus@samba.org \
--cc=viro@ftp.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox