Re: [gomd-devel] <DAEMON> Next step: chpox support

[Matthias Rechenburg]

Hi JP,

On Sonntag 26 Oktober 2003 13:28, Gian Paolo Ghilardi wrote:
> Hi all.

sorry for the delay

>
> My box is fully operational and I'd like to start coding the chpox support.

good :)

> Unfortunately I've some problems installing the chpox stuff but I thinks
> this prob is due to my recent compiler upgrade (kernel was built with gcc
> 3.2.3 while now I'm using the 3.3.1 version => I'll recompile all the
> stuff).
>
> These are some points we have to discuss:
> 1)IMHO, we should contact the chpox authors to start a fruitful
> cooperation. I think this is an important point as they can help us a lot.

yep

> 2)I'd like to automatize all the possible stuff.
> 3)My idea is simple:
> - by default all migrated apps are chpointed.
> - users can define the chpoint interval/rate
> - users can choose what need chpointing (i.e. "all "amber" apps, all heavy
> procs,...").
>   The optimum, IMHO, is to provide a "natural" (and coherent with the rest
> of the code) way to do this stuff
>   I.e we can reach this via simple MACROS like: CHPOX_HEAVY_PROCS,
> CHPOX_DEFAULT_BEHAVIOUR, CHPOX_TIME_INTERVAL, ...
> - obviously this stuff will be excuted in separate threads: a main
> chpox_support thread (that handles client requests and default settings) +
> several worker threads (one for each chpointing/restoring activity).
>    As chpox is marked as "thread-safe" this should be quickly implemented.
> 4)Libgomd will feature new simple functions to activate _directly_ the
> chpointing/restoring stuff.

ok, here is my mind to the chpox "thing" ;))
First i do not think there is an easy way to automate this e.g.
processes may be not always doing heavy computing and
they can migrate back and forth. 
If we checkpoint processes which are migrated what will we 
do if the processes returns home ?

To my mind we should provide only "low-level" functions for
the chpox support e.g. a gomd function which accepts
 "reg [PID"
 "chkp [PID]"
 "unreg [PID"

All "high-level" stuff e.g. decide which processes to register/checkpoint
can be simply done in the "user-application" by a combination of already
provided features from the gomd e.g. 
 ...
  libgomd->get processlist
  find the 5 heaviest computing processes
  for each of those 5 do
     libgomd->reg [PID]
     libgomd->chkp [PID]
  done
...

 (...excuse the syntax ;P )

Which process should be checkpointed is a user-decision so if we
provide only those low-level functions it should be enough.

one "semi-automatic" idea is to automatically checkpoint all
registerd processes (registered manually by the user).

..... and yes, it will be also good if there is a fully automatic
checkpointing feature which finds+checkpoints processes
by it own decision/intelligence  ;)) should be an additional feature.

Another issue is maybe a new config parameter for the gomd.conf
-> checkpoint dir
for storing the process-dumps. This should be configurable by
the user too ;))

>
> This is only a preliminar draft for implementing chpox.
> As this can be the "killer-feature" for gomd this stuff is very important.

yes, agree

>
> Any idea/hint/criticism is welcome (as usual). ;)
>
> Byez.
>
> <rejected>
>
<snip>

cheers,

Matt
-- 
E-mail  :  address@hidden
www     : http://www.openmosixview.com
an openMosix-cluster management GUI

Be safety conscious.  80% of people are caused by accidents.