Re: Ksplice equivalent for VMS ?

On 2/19/2025 10:07 PM, Dan Cross wrote:

In article <vp65ns$2gh03$1@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 2/19/2025 9:26 PM, Dan Cross wrote:

In article <67b66f14$0$712$14726298@news.sunsite.dk>,
Arne Vajhøj  <arne@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.

VMS nodes in a VMS cluster with a some common VMS cluster setup.
That does mean same administrative domain, but more than that.

                               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.

Process migration would be a big huge task to implement.
But VSI are not considering the ksplice model, so I wanted to
know if they are considering the process migration model.
Arne