gomd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Johnny Cache
Subject: Re: [gomd-devel] <DAEMON> Next step: chpox support
Date: Sun, 26 Oct 2003 14:55:47 -0600 (CST)

Heya rejected, all that sounds really good to me but im a bit confused on
the LIBgomd chpox support. I always imagined like a system wide policy for
checkpoint procs, like you described. what would the library interface be
good for? if a program wants to register itself ?

adios
-jc


On Sun, 26 Oct 2003, Gian Paolo Ghilardi wrote:

> Hi all.
>
> My box is fully operational and I'd like to start coding the chpox support.
> 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.
> 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.
>
> This is only a preliminar draft for implementing chpox.
> As this can be the "killer-feature" for gomd this stuff is very important.
>
> Any idea/hint/criticism is welcome (as usual). ;)
>
> Byez.
>
> <rejected>
>
>
>
>
>
>
>
>
> _______________________________________________
> gomd-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gomd-devel
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]