All of lore.kernel.org
 help / color / mirror / Atom feed
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
To: Andrew.Tridgell@anu.edu.au
Cc: lm@gate1-neteng.engr.sgi.com, linux-mc@arvidsjaur.anu.edu.au,
	Linus.Torvalds@cs.Helsinki.FI, linux@neteng.engr.sgi.com,
	alan@cymru.net
Subject: Re: mpp kernel interface
Date: Thu, 16 May 1996 18:19:16 +0100 (BST)	[thread overview]
Message-ID: <m0uK6ho-0005FbC@lightning.swansea.linux.org.uk> (raw)
In-Reply-To: <199605161420.AAA24100@arvidsjaur.anu.edu.au> from "Andrew Tridgell" at May 17, 96 00:20:34 am

> We use sockets to implement the stdin/stdout/stderr of parallel
> processes. The paralleld that launches parallel programs on each cell
> first creates 3 sockets back to the launching program, setting them up
> as file desciptors 0, 1 and 2. When it then does a fork()/exec() the
> parallel program inherits them.

Two things strike me here. Firstly if you are doing that kind of output
redirection across 192 cells you are going to need 192 logical connections
however you do it. Secondly you really want your node end library to be
a bit smarter and pass a tty check across the link so you can use tty/pty
pairs if the real descriptor is a tty.

> parallel programs. If we had a remote fork() and/or remote exec()
> and also had a way for the file descriptors of remote forked processes
> to feed back into the parent cpu then it would be much better. 

MOSIX does this by trapping them at the VFS layer. Effectively each inode
and file handle has a host field and if the operation is remote you RPC.

> We'd probably also need to use a tree structure to feed the file
> descriptors (and paging for that matter) back up into the parent
> process. 1000 children all writing to one parent would not be pretty. 

It would be an interesting application of multicast groups to allow the parent
to roam as well. With 1000 children thats an even bigger scaling problem, and
for sending stuff to a large number of nodes (eg a loosely synchronized SIMD
job) its going to be needed.

> The problem is really latency. Ethernet type systems have latencies
> which aren't much lower than the system clock tick interval. This
> means it often makes sense to do things is quite different ways to
> what we have to do.

Yes. The latency also means that attacking from two other angles is interesting
Firstly 10Mbit ethernet - latency is no worse really just we have to be more
reluctant to bulk copy data, and also combining it with something like the
TTL PAPERS device for the fast sync stuff (its a $60 to build parallel port
synchronization system with about a 3uS overhead). Very limited but might
solve some of our problems on ethernet linked boxes.

Alan

      reply	other threads:[~1996-05-16 22:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-05-15 22:43 mpp kernel interface Larry McVoy
1996-05-16  9:09 ` Alan Cox
1996-05-16  9:09   ` Alan Cox
1996-05-16 14:20 ` Andrew Tridgell
1996-05-16 17:19   ` Alan Cox [this message]

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=m0uK6ho-0005FbC@lightning.swansea.linux.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=Andrew.Tridgell@anu.edu.au \
    --cc=Linus.Torvalds@cs.Helsinki.FI \
    --cc=alan@cymru.net \
    --cc=linux-mc@arvidsjaur.anu.edu.au \
    --cc=linux@neteng.engr.sgi.com \
    --cc=lm@gate1-neteng.engr.sgi.com \
    /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.