linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg KH <greg@kroah.com>,
	linuxppc64-dev@ozlabs.org, linux-kernel@vger.kernel.org,
	Paul Mackerras <paulus@samba.org>,
	Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH 7/8] ppc64: SPU file system
Date: Sun, 15 May 2005 12:08:52 +0200	[thread overview]
Message-ID: <200505151208.54229.arnd@arndb.de> (raw)
In-Reply-To: <1116138546.5095.6.camel@gaston>

On Sünndag 15 Mai 2005 08:29, Benjamin Herrenschmidt wrote:
> Why not just write(pc) to start and read back status from the same
> file ?

I suppose you are thinking of the simple_transaction_read() style
interface. I've got the feeling that this is generally even
less popular than ioctl because 

- it is still an untyped interface (as would be a read() based one)
- you can't do 32 bit emulation (doesn't matter for me, we only
  have 32 bit data)
- it is non-atomic
- it doubles the system call overhead

One operation that I want to allow is to have an infinite loop
running on the SPU that does a simple operation (e.g. process
one MPEG macroblock) and have that called by multiple unrelated
processes in turns. When my operation is not atomic, users need
to have additional IPC serialization of their accesses. Most
would want that anyway, but it is not a requirement with an
interface that needs only a single system call.

For the extra syscall overhead, I would like to see measurements
of a real world application before I change to an interface that
is slower in theory. Do you have measurements for the time spent
in a trivial system call on G5 or Power4?

	Arnd <><

  reply	other threads:[~2005-05-15 10:25 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-13 19:31 [PATCH 0/8] ppc64: Introduce Cell/BPA platform, v2 Arnd Bergmann
2005-05-13 19:21 ` [PATCH 1/8] ppc64: split out generic rtas code from pSeries_pci.c Arnd Bergmann
2005-05-13 19:23 ` [PATCH 2/8] ppc64: add a minimal nvram driver Arnd Bergmann
2005-05-13 19:24 ` [PATCH 3/8] ppc64: add a watchdog driver for rtas Arnd Bergmann
2005-05-17 20:40   ` Nathan Lynch
2005-05-18  7:14     ` Arnd Bergmann
2005-05-18 14:45       ` Nathan Lynch
2005-05-18 14:39         ` Arnd Bergmann
2005-05-13 19:25 ` [PATCH 4/8] ppc64: add BPA platform type Arnd Bergmann
2005-05-17  7:01   ` Paul Mackerras
2005-05-17 11:05     ` Arnd Bergmann
2005-05-13 19:26 ` [PATCH 5/8] ppc64: Add driver for BPA interrupt controllers Arnd Bergmann
2005-05-13 19:27 ` [PATCH 6/8] ppc64: Add driver for BPA iommu Arnd Bergmann
2005-05-13 19:29 ` [PATCH 7/8] ppc64: SPU file system Arnd Bergmann
2005-05-13 23:31   ` Benjamin Herrenschmidt
2005-05-15  9:07     ` Pavel Machek
2005-05-15 12:02       ` Benjamin Herrenschmidt
2005-05-15 12:33         ` Arnd Bergmann
2005-05-14  7:45   ` Greg KH
2005-05-14 13:05     ` Arnd Bergmann
2005-05-15  6:29       ` Benjamin Herrenschmidt
2005-05-15 10:08         ` Arnd Bergmann [this message]
2005-05-15 11:50           ` Arnd Bergmann
2005-05-16 20:58       ` Greg KH
2005-05-16 22:01         ` Arnd Bergmann
2005-05-16 22:27           ` Greg KH
2005-05-16 22:22             ` Arnd Bergmann
2005-05-16 22:49               ` Greg KH
2005-05-15 11:24     ` Andi Kleen
2005-05-16 20:14     ` Roland Dreier
2005-05-16 20:53       ` Greg KH
2005-05-18 12:40     ` [PATCH] libfs: add simple attribute files Arnd Bergmann
2005-05-18 20:24       ` Greg KH
2005-05-19  8:29         ` Arnd Bergmann
2005-05-19  9:18           ` 2.4 Kernel threads linux
2005-06-10  4:33           ` [PATCH] libfs: add simple attribute files Greg KH
2005-05-13 19:32 ` [PATCH 8/8] ppc64: add spufs user library 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=200505151208.54229.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=anton@samba.org \
    --cc=benh@kernel.crashing.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc64-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /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;
as well as URLs for NNTP newsgroup(s).