[Info-vax] Ksplice equivalent for VMS ?

[Arne Vajhøj]

On 2/19/2025 10:07 PM, Dan Cross wrote:
> 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.

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