modred team mailing list archive

[Scott Lawrence <bytbox@xxxxxxxxx>]

I think we should start building prototypes before we start debating
fine techinical points in supporting various obscure types of IPC,
hmm?

Lisp ok with everyone?

On 12/30/09, Frederic Koehler <fkfire@xxxxxxxxx> wrote:
> Actually, shared mmap could be supported if the programs were forced to run
> on a single server (would need special hints).
>
> On Wed, Dec 30, 2009 at 7:35 PM, Frederic Koehler <fkfire@xxxxxxxxx> wrote:
>
>> So a normal, single-process program would run on one server, right?
>> And then theroretically it's resources would be shared like on a normal
>> computer,
>> like there would be a distributed file-system, cross-computer IPC, and the
>> like?
>>
>> This would be like a more user-spacish mosix (http://www.mosix.org, might
>> be interesting to read about), it's also somewhat like OpenVMS clustering,
>> I
>> think. Of course, both of those involve custom kernels, and aren't totally
>> similar, but the same conceptual use, right?
>>
>> As far as IPC, there is no obvious problem with traditional pipes/sockets,
>> but IPC through shared mmap is most likely impossible to support (even
>> MOSIX
>> doesn't support it) (technically speaking, it _might_ be supportable with
>> absolutely horrible performance, but probably unworthwhile).
>>
>>
>> On Wed, Dec 30, 2009 at 1:19 PM, Scott Lawrence <bytbox@xxxxxxxxx> wrote:
>>
>>> My idea here, as I explained to Mikey last night over chat, is that
>>> the transparent access allows us to run programs out-of-the-box. Most
>>> programs won't perform well like this, for various reasons, and that's
>>> fine, a few will perform ok, and a few might happen to perform
>>> excellently.  But these programs could be tweaked by telling the
>>> cluster that when the program forks in such-and-such place, it should
>>> be put on another computer, and the program should generally be
>>> packaged with the following data, etc... etc..., and stuff like that
>>> to minimize network usage.
>>>
>>> Programs written for the cluster will generally not want to use the
>>> transparent features.  Of course, if they do, it'll still work.
>>>
>>>
>>> On 12/30/09, Michael Cohen <gnurdux@xxxxxxxxx> wrote:
>>> > If you want networked memory access, you need to be using mmap()
>>> > somewhere.  I agree with you that it is probably not such a great idea;
>>> > Scott wants transparent stuff over the cluster but in reality that is
>>> > probably pretty much not a possibility, as there is a big difference
>>> > between .0000001 second latency and .1 second latency, so any code that
>>> > makes almost any use of any inter-process communication would run many
>>> > times slower on the cluster than on one computer.
>>> >
>>> > Michael Cohen
>>> >
>>> > Frederic Koehler wrote:
>>> >> Uh...what exactly is this supposed to be used for?
>>> >>
>>> >> Trying to abstract networked data as mmap over some type of network
>>> file
>>> >> system
>>> >> is an ok option, but it's not simple (for one, figuring out the
>>> >> synchronization and the like, and also having to build a file system
>>> >> or
>>> >> finding some obscure one which meets requirements).
>>> >>
>>> >> Also, it's not easily usable for clients, so if they need to access
>>> data
>>> >> they still probably need some more traditional interface.
>>> >>
>>> >> On the other hand, a more traditional interface (for ex. cloning
>>> read(),
>>> >> write() and the like in a user-space library, or some other approach)
>>> >> could
>>> >> be used for both.
>>> >>
>>> >> Anyway, though, doing lots of reading/writing over the network is
>>> really
>>> >> bad
>>> >> performance-wise (it clogs up the network and has horrible latency),
>>> >> so
>>> I
>>> >> don't know if whatever you're planning is actually a good idea
>>> (especially
>>> >> if "memory access often involves the cluster"...).
>>> >>
>>> >>
>>> >> On Wed, Dec 30, 2009 at 12:01 AM, Michael Cohen <gnurdux@xxxxxxxxx>
>>> wrote:
>>> >>
>>> >>> I just realized that we could actually do this by mmapping to stuff
>>> >>> in
>>> >>> some
>>> >>> kind of network file system.  It might be a little tricky to ensure
>>> that
>>> >>> the
>>> >>> data is actually up to date, but it probably could be done.
>>> >>>
>>> >>> Michael Cohen
>>> >>>
>>> >>>
>>> >>> Scott Lawrence wrote:
>>> >>>
>>> >>>> I, the perennial linux newbie, was somehow under the impression that
>>> >>>> memory access was a system call.  Ouch.
>>> >>>>
>>> >>>> So the issue is that memory access often involves the cluster, and
>>> >>>> so
>>> >>>> we should have a fast way to interrupt it to talk over the network.
>>> >>>> (Obviously, we wouldn't re-fetch the same data repeatedly.)
>>> >>>>
>>> >>>> Mikey suggested mmap.  The issue is that this only maps to actual
>>> >>>> files, so it wouldn't work for network access.  Anyone know of a way
>>> >>>> to mount a kernel driver in user space?  Or is there a better way?
>>> >>>>
>>> >>>>
>>> >>> _______________________________________________
>>> >>> Mailing list: https://launchpad.net/~modred
>>> >>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>> >>> Unsubscribe : https://launchpad.net/~modred
>>> >>> More help   : https://help.launchpad.net/ListHelp
>>> >>>
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Mailing list: https://launchpad.net/~modred
>>> > Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>> > Unsubscribe : https://launchpad.net/~modred
>>> > More help   : https://help.launchpad.net/ListHelp
>>> >
>>>
>>>
>>> --
>>> Scott Lawrence
>>>
>>> Webmaster
>>> The Blair Robot Project
>>> Montgomery Blair High School
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~modred
>>> Post to     : modred@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~modred
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>


-- 
Scott Lawrence

Webmaster
The Blair Robot Project
Montgomery Blair High School