🚀 go-pugleaf

In article <51b7861a.20b6d@apollo.HP.COM>, goykhman_a@apollo.HP.COM
(Alex Goykhman) writes:
|>>Because of 3/ and 5/ the eager copying of UNIX fork put UNIX out of
the game.
|>>
|>>We then put some hope in the lazy copying of MACH.  The problem then
appeared
|>>to be that MACH as well as UNIX is not designed for applications which
|>>need intensive forking of "threads" of computation which have their own 
|>>separate adress spaces. ....................................................
|>
|>    Why do you think so?
|>
|>
|>>....................... The task in MACH  is a coarse grain entity which
|>>have a whole bunch of available facilities like files, communication
|>>port which are not always needed but are always there. A task is
consequently
|>>costly to create, to schedule and to terminate.
|>
|>    Files???  Contextwise, a MACH task is (mostly) a collection of VM
regions. 
|>    Considering the way MACH manages memory (page aliasing), creating a new
|>    task/context should be relatively cheap.
|>>


It is claimed that Mach is able to fork off tasks in constant time
(without taking into account the cost of future page faults due to copy-on-
write copying). It simply can not be true.

All the pages inherited by the children which have the copy-on-write property
have to be set to read-only before forking in order to trigger
the copy-on-write. This implies a scan of the region for modifying the pages
properties and to invalidate the corresponding TLB entries for these pages.
This has a LINEAR cost.

When it is claimed that that the cots is constant, I do not conclude
that the designers are liars but  that this linear cost is simply hidden
by some other CONSTANT costs which are usuallly much bigger.

Since all I would be interested in task forking is the virtual memory handling
I conclude that MACH does not fulfill my needs.

|>>                             ------------- : Owned by Thread1
|>>                             ------------- : Owned by Thread2
|>>                             -------------
|>>     |-----Shared space----| Private space |--------Shared space -------|
|>>                             ------------- : ....
|>>                             ------------- : ....
|>>                             ------------- : Owned by ThreadN...
|>
|>    I am not sure what you mean by "private", since you also indicate that a 
|>    "private" region will be read-shared with the parent task.
|>

In the scheme I want, parent threads/processes are suspended until thier
offsprings terminate. Private means that the sibling threads/processes
do not see thei respective private regions.

|>    What you are really looking for is a VM_INHERIT_MOVE inheretance
attribute
|>    in addition to VM_INHERIT_SHARE, 0VM_INHERIT_COPY, VM_INHERIT_NONE
already
|>    provided by MACH.  While it would be nice to have one supported by MACH,
|>    you should be able to achieve similar results with VM_INHERIT_COPY and 
|>    vm_deallocate(parent_task).  
|>
|>> Within a quantum of time allocated
|>>to a global "task" (not a MACH task any more) context switching between
|>>these threads/processes is cheap - the cost is the one of a unmapping 
|>>the pages of one thread/process and mapping those of the next one.
|>>Since the concept of private region is hardwired in the paradigm
|>>all virtual memory handling can be done at forking
time/context-switching time
|>>when the system is in kernel mode. No additional and unelegant system calls
|>>are need to set up  the execution environement of a newly created/scheduled
|>>thread/process. Moreover teh resources (physical pages) allocated to a
|>>terminated
|>>thread can be kept by the "task" and ready to be allocated to the
next created
|>>thread/process.
|>
|>    Looks like you just reinvented the MACH :)


You are hard with me !! :->.
If such memory handling is mimicked in MACH with tasks and VM_INHERIT_COPY,
this does not work because taks are considered to be independent entities.
Hence during task context-switch all the pages of the scheduled out task
are removed form the TLB (Ok it may not be that bad if your MMU has a context
information in its TLB lines but still....).

My point is that since I know that these threads/processes are tightly
connected
I do not want to remove the TLB entries other than the ones from the
private regions.

You cant do that in MACH

BTW: I would need a forking time of less than 1 ms with a private region
(or VM_INHERIT_COPY region) has big as possible.