[Info-vax] Ksplice equivalent for VMS ?

Dan Cross cross at spitfire.i.gajendra.net
Wed Feb 19 22:07:30 EST 2025


In article <vp65ns$2gh03$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 2/19/2025 9:26 PM, Dan Cross wrote:
>> In article <67b66f14$0$712$14726298 at news.sunsite.dk>,
>> Arne Vajhøj  <arne at vajhoej.dk> wrote:
>>>[snip]
>>> Yes. Which becomes a little easier when restricted to a
>>> cluster instead of any systems.
>> 
>> I don't know what you mean when you say, "restricted to a
>> cluster instead of any systems."
>
>A and B being in a cluster instead of being two
>standalone nodes.

Oh I see, you're using cluster here as a shorthand to
mean that they're in the same administrative domain.

>>                               If you mean that this somehow
>> makes managing state during process migration easier, then no,
>> not really; all of the same caveats apply.  For instance,
>> if a program is using (say) a GPU for computation, part of
>> migrating it will be extracting whatever state it has in the
>> GPU out of the GPU, and replicating it on the destination
>> system.
>> 
>> At one point, the internal numbering of cores in the GPU was
>> visible to code running on the GPU, creating an $n \choose k$
>> fingerprinting problem for migration.
>
>A VMS server process will not be using GPU.

Sure.  GPUs, as compute accelerators, are just one example.
It could be some other resource.  The point is, process-level
migration is not a panacea; ksplice has its place, even with
its limitations.

>I guess as part of the migration the process would need to
>be non-CUR and release CPU (and GPU if VMS adds support for
>CUDA or similar in the future).
>
>Main memory will need to be migrated. And cluster will
>not help with that.
>
>But cluster with shared storage will help with disk files.
>
>And cluster with shared SYSUAF will help with identity.
>
>And cluster with shared queue database will help with jobs.
>
>> Besides, clusters can contain heterogenous systems.
>
>Yes.
>
>The nodes would need to be compatible.
>
>Mixed architecture cluster is definitely out
>of the question.
>
>:-)

Correct.

	- Dan C.



More information about the Info-vax mailing list