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

[Johnny Cache]

Those all sound good to me, i also have a few suggestions:
a feature to automatically checkpoint any "long running" processes
where "long running" can be defined in a config file
This sounds like a good job for gomd, since anything that would
be able to do this needs to know what processes are around and how long
they have ben around. I tihnk it would be kind of silly to have a
"checkpoint daemon" but maybe someone else would disagree

Also, while this isn't relaly our departmenti think that once the chpox
stuff is more solidly integrated it owuld be handy to have a argument to
mosrun to enable checkpoint every N minutes.

good ideas? bad ideas?
Best Regards
-jc


>
> > 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.
>
>
>
> _______________________________________________
> gomd-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomd-devel
>