Re: [microblaze-uclinux] Re: multiprocessing

[Greg Ungerer <gerg@xxxxxxxxxxxx>]

Hi Matthew,

Matthew Rubenstein wrote:
> 	Greg, it looks like we've got a sanity problem, with unsync'd frames of
> reference ;). I think we actually agree;

I agree, I think we are just hashing the details.



>>Matthew Rubenstein wrote:
>>>	Children of fork()'ed processes inherit their parent's state, with page
>>>tables managed by the MMU (unless I'm mistaken).
>>
>>With a standard fork() the child gets a new virtual address space
>>that looks identical to the parents (often optimized with COW, but
>>that is not relevant here). It has its own set of page tables that
>>hold this mapping. The "management" of page tables is done by the
>>kernel, not so much the hardware. So any processes page tables are
>>just a part of its "state". A child inherits a _copy_ of its
>>parents page tables on a fork(). On a vfork() the child uses its
>>parents page tables.
> 
> 
> 	Yes - The MMU manages the creation of the child's duplicate page
> tables. Without one (or a replacement in SW/firmware), the child uses
> its parent's.

Not quite. The creation of the childs page tables is done by the kernel.
Thus my point earlier that the kernel does page table management.
The MMU hardware does the on-the-fly translations of virtual to phsyical
and traps on illegal accesses. It is the kernels responsibility though
to create, modify and destroy the actual page table entries.

A child uses its parents, or a copy of its parents, because the
kernel setup its state that way.


> I might have been mistaken that the MMU is the missing
> link to a viable fork()'s set of child page tables, but revisiting some
> literature suggests that I'm not. Unless you know of a fork() that
> results in child page tables without an MMU.

It really makes no sense to talk about page tables without an MMU.
An MMU implements the page table mechanism.

But there exists other types of memory hardware support mechanisms
that allow implementing a fork that don't use the paged technique.
Segments is one way. But lets face it, paging is by far the most
common technique and the one favored by pretty much all modern
hardware.


> But the point is that, yes,
> the child has only its parent's actual state itself within which to
> work.

Yes, at the time of the fork/vfork.


>>> Regardless of the (lack
>>>of?) the missing MMU as raison d'etre, vfork() offers only preservation
>>>of parent's state, with a few volatile accesses offered from the child
>>>to the parent, for write, and fewer for read, and even fewer for return
>>>to the parent.
>>
>>Huh?  This doesn't make any sense to me...
>>What accesses are you talking about?
> 
> 
> # man vfork [edited]
> ...[undefined on] any data other than a variable of type pid_t used to
> store  the  return value from vfork()...
> 
> 	I mean that even if the MMU isn't the reason for the availablity of
> vfork(), instead of fork(), vfork() is all we've got, and that means we
> don't get fork()'s full parent state, or fork()'s protection of the
> parent's state from writes from a badly written or broken child, or any
> facility to return data to the parent other than the PID of the vfork()
> call itself (though the parent state could include a writable pointer to
> allocated memory and registers which the child could use as buffers and
> flags for return values). So vfork isn't as useful as fork().

True, vfork is not as usefull as fork, but I don't think for the
reasons you give. Even with fork the child cannot pass information
back to the parent within its own state. The child has a complete
_copy_ of the parents memory. So anything it modifies is only within
itself - the parent will not see those changes.

Using either fork or vfork the child can only use the same mechanisms
to return data to the parent (message passing, signal passing, etc).
[This assumes that the vfork child follows the rules as laid out in
the manual page].

The limitation with vfork is that you cannot continue to run and
be a separate instance of the same program. Like the classic server
model of operation (samba, apache, etc).


>>A child process that modifies the parent state in any way
>>is broken. From the vfork() manpage:
>>
>>     The vfork() function has the same effect as fork(), except that
>>     the behaviour is undefined if the process created  by  vfork()
>>     either modifies any data other than a variable of type pid_t used
>>     to store the return value from vfork(), or returns from the
>>     function  in which vfork() was called, or calls any other function
>>     before successfully calling _exit() or one of the exec family of
>>     functions.
> 
> 
> 	We're in violent agreement :). I just apparently distrust vfork() more
> than you do, for the same reasons.

It surely can get you into trouble if you don't use it right :-)


>>>And there's no simulated (interleaved) multitasking; the
>>>parent halts until the child terminates and is destroyed.
> 
> 
> 	On a uniprocessing CPU, like any Harvard arch, like MicroBlaze, all
> multitasking is achieved through simulation of "simultaneity" of
> multiple processes, using the weaker "concurrency" of execution.
> Multiple "simultaneous" processes are juggled, usually round robin,
> executing a few instructions from each in succession: interleaving short
> sequences achieves the illusion of simultaneity, like a juggler's trick.
> Parent starts, spawns child, parent halts, child executes, child halts,
> parent executes, parent halts, child executes, repeat (usually
> thousands/millions of cycles, and across dozens/hundreds of processes),
> parent or child terminates and is destroyed (removed from memory),
> remaining processes continue in their timeslices, etc.
> 
> 
> 
>>This is true. But it over looks the whole reason that vfork()
>>was created. _Most_ programs fork() then immediadely exec()
>>another. And when that exec() occurs the child builds a new
>>process memory state. At this time the parent then continues -
>>entering the run queue. So now we have the child and parent
>>multitasking again (simulated or otherwise).
> 
> 
> 	vfork() lets you port code that fork()'s, if you revise the child not
> to require its own state. I find the entire simulated multitasking I
> describe above to be an inefficient hack, and like most HDL programmers,
> prefer true multiprocessing. I dislike vfork(), because it's the fork();
> exec() paradigm that I dislike, without even fork()'s fuller support for
> the parent/child paradigm I'm still stuck with. In short, I don't like
> multitasking through simulated multiprocessing: I prefer real
> multiprocessing hardware, especially when I have to deal with the actual
> details of the simulation.

I guess it is fair to say the current simulated multi-tasking is
a sort of hack. But it has proved wonderfully useful over the years.
And from an implementation point of view it is not terribly difficult
to do.


>>Well, I can't say I agree with that. fork() seemes to have served
>>as quite a strong fundamental primitive over the years. You can argue
>>its ineffeciency with regard to spawning different programs.
> 
> 
> 	When all you have is a hammer, everything looks like a nail. I like
> FPGA because of true multiprocessing (among other features). fork() has
> served well enough - we're currently depending on it to correspond quite
> pleasantly across an entire planet, mostly ocean (greetings from New
> York City :). But programming FPGA has been much harder than programming
> Harvard arch CPUs, with fewer tools, and no instances of the old
> environment (OS/shell) executing in the FPGA itself. Until MicroBlaze.
> Now that we've got one eye, everyone else starts to look blind. And
> that's the way to become king ;).

It will be interresting to see what we can do with these types of 
engines. But like you say, it has proved to be not simple to make
them do really usefull things in a general way.


[snip]
> 	Well, reconfiguring MicroBlaze on the fly is about as interesting as
> "reflexive programming" pure software, like programmatically revising
> code in a string passed to eval(). Or C++ templates. Quite powerful, but
> esoteric enough to be rare, and hard to maintain among different
> programmers. Although VLIW programmers will love it, and multiprotocol
> Internet routers will be much more reliable and faster. I'm more excited
> about a MicroBlaze program that can retrieve FPGA config files from disk
> or memory, reconfig the remaining unallocated gates, and call those
> functions during execution. Even if the program just starts up, gets the
> latest version of the glue logic for its neighboring support chips, and
> continues its execution only in its uniprocessing MicroBlaze CPU thread,
> the savings and efficiency of downloadable, onchip glue logic will be
> superior to hardcoded CPUs in many cutting edge applications. 
> 	Even more exciting is loading multiprocessing logic that can be called
> from a single function call in the uniprocessing program offers to
> balance the best of both worlds of uni/multiprocessing, in the same
> application. Then the architectural opportunities for runtime feedback
> to the gates configuration offers a new level of intelligence to these
> programs, while leveraging all the applicable techniques and software
> from the last generations of hardcoded hardware. For example, a program
> running in MicroBlaze has to decode an audio stream. It reads the
> header, detects the format, then loads the decoder for that format from
> disk to the gates. Realtime DSP becomes possible, and the benefits that
> Intel crowed about for "NSP" (Native Signal Processing) actually arrive
> intact. Next track is in a different format? Just overwrite the decoder
> gates with that format's decoder from a disk file. And the rest of the
> program, which doesn't vary with IO conditions, is a direct port of a
> free/open PowerPC app. (I shiver with excitement :).

For me this seems a little too easy. I figure we can almost do this now.
Loading things on demand that we already know about (we know in advance
what codecs will be used in the above example). It would be much more
interresting if we could be clever about this on the fly.


> 	Going from that environment, to gates that dynamically reconfigure on
> the fly, will be less of a leap than just going from Pentium programming
> to reconfig utopia. Especially for newer programmers, who never learned
> bad habits (like vfork() - sorry :) necessary to work in the old
> uniprocessing environment. So much of the exciting mobile multimedia
> telecommunications future will benefit from genetic algorithms, fuzzy
> logic, neural networks, geometric evaluation, as well as the vast
> experience in procedural programming of English language policies. I'm
> very excited about MicroBlaze as the vehicle that gets to that future.
> In fact, I believe that the future has now already arrived, we're just
> catching up to it. If MicroBlaze offered only the same uCLinux features
> as on an ARM or Geode, why use it, except to exercise the fetish ;)?

Well for one reason because no I can put on 1 chip all the periperhals
that I need to use X chips for now. Insetad of laying down a CPU, a
network engine, etc, I can lay down a single FPGA that is everything
on one. One day it may even be cheaper :-)

Or maybe I can lay down 4 or 8 or more Microblaze cores on a single
FPGA and do something clever with traditional SMP.


> What apps are *you* targetting with this platform?

None :-)
I have never run uClinux on a Microblaze. But as a maintainer of uClinux
I like to follow here to see what is going on.


> 	Thanks for the opportunity to articulate my point with a critical edge
> keeping me honest :). Especially since we seem to agree, when I can
> express my points in understandable terms.

Indeed :-)
Good to see some lively debate!

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Dude       EMAIL:     gerg@snapgear.com
SnapGear -- a CyberGuard Company            PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/