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

[Matthias Rechenburg]

Hey Johnny,

On Dienstag 28 Oktober 2003 20:58, Johnny Cache wrote:
> 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

yesss, nice idea for a possible automatism

> 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

yep, not another daemon but gomd ;))

>
> 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?

good ideas

> Best Regards
> -jc

howdy,

Matt

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

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

If debugging is the process of removing bugs, then
programming must be the process of putting them in.