All of lore.kernel.org
 help / color / mirror / Atom feed
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?


  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 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.